I’m a large proponent of adopting cryptocurrency and blockchain projects for their actual usage – rarely for speculation or hodling. In general, rampant speculation drowns out meaningful education. However, with the diverse amount of projects released, it was only a matter of time before projects sprung up that reached back to the “fin” part of their fintech roots.

All three major types of cryptocurrencies – transactional, platform and utility – are seeing a crop of projects that are meant specifically for holding as a form of passive and investment income.

Since a plethora of content already exists around mining and since it requires a high barrier to entry relative to traditional income/passive investments, let’s focus on some more attainable alternatives.

Traditional investment (and our friends at the IRS) differentiate capital investments and passive investments based on where the investor derives his/her literal returns. A return realized on the sale of an investment asset (say, selling an ICO token after it rose in value), is considered a capital investment. A return, or income, realized independently of an asset bought or sold is considered an income or passive investment. The clearest cut example here from traditional finance is dividends from stocks held.  

Passive income is the most highly sought-after form of investment since it’s the literal actualization of “your money working for you.” Yet passive income is notoriously hard to attain. From Airbnb, to blogging with affiliate links, to collecting stock dividends, to franchising, to leasing real estate, passive income is really hard to capitalize on and often becomes less passive than intended. Additionally, passive income often requires large upfront capital and more importantly, time, yet often returns less than ideal rewards.

Thankfully, a few pioneers from crypto-world are turning the tide by offering a few different methods that resemble income and passive investments.

*Editor’s note: You already know what this is going to say. The second you saw “editor’s note”, you got ready for that “this isn’t investment advice” statement. We can’t stress it enough that this isn’t investment advice, and is purely informational. Cryptocurrencies are very volatile – gain/lose money on your own research and advice from licensed and experience professional providers.

Different Ways Of Earning Dividends In Crypto

There is no exact comparison for dividends within crypto-world, however, there are multiple different other ways of holding cryptocurrencies for a passive return. No two projects are exactly alike in the process either, so be wary that additional research is required for any method suggested below.

The following is a list of the general ways a cryptocurrency can offer passive income:

• • Staking – holding a Proof-of-Stake coin in a special wallet
  • Master Node –  controlling a Masternode
  • Utility Tokens – holding tokens designed for periodic income

Staking

Blockchains and cryptocurrencies use special algorithms, known as consensus algorithms, that mathematically determine which next block is the “right” one. Bitcoin introduced the most popular type of consensus algorithm known as Proof-of-Work. By far and large PoW is the most popular form of consensus within crypto world.

However, an increasingly-popular second form of consensus, Proof-of-Stake, is slowly but surely starting to take off. This leads us to door number one for creating passive crypto income: staking.

In Proof-of-Stake, instead of mining for cryptocurrencies through hardware, new blocks are created by holding cryptocurrencies in a staking wallet. A staker puts up a stake (coins), or locks up a number of their coins, to verify a block of transactions. Ideally, the more coins one stakes, the bigger the chances are that one will be awarded a block reward.

Some coins require a 24/7 connection and power-source, while others require very literally just holding coins in a special wallet. From my research, NEO takes the cake in terms of lowest barrier to entry both fiscally and computer-literacy-wise. All it took was downloading the official City-of-Zion NEON wallet and transferring purchased NEO from exchange to said wallet.

That’s it! As long as I keep my NEO in the official wallet it’s already staked — no additional steps necessary and I can claim my staked rewards (in GAS) up to every 5 minutes. As far as the “passive” part of passive investment goes, PoS certainly fits the bills.

Among other cryptocurrencies now offering rewards through PoS staking are NEO/GAS, Lisk, Stratis, and ARK.

Masternode

Method number two for leveraging an income stream from crypto-holdings more resembles traditional passive income as it typically requires a substantial amount of startup capital. A growing number of crypto-projects have two or more layers of governance — with the upper, higher-power layer, or node, commonly referred to as the masternode.

These master nodes usually provide some additional governing effort to its underlying crypto-community. Some examples are actively/passively voting on software updates, verifying private/instant transactions, and participating in community events.

Holders of master nodes are usually rewarded handsomely. For example, in Dash, masternodes receive a whopping 45% of the block reward on every single new block. The official Dash website claims that “typically, around 2 Dash (~$325) is paid to each masternode every 7 days.”

What’s the cost to own a master node you say? Well, that depends on which coin we’re discussing – to continue with Dash, a masternode costs 1000 Dash locked up for a fixed period of time. Unfortunately, not many crypto-enthusiasts have ~$325K liquid lying around that they’re willing to tie to a single coin.

Utility Tokens

This final category represents the widest range of projects as each passive income derives its value from the success (or failure) of a tokens main utility; the core difference between the PoS model previously defined and this utility token model stems from exactly which part of the cryptocurrency project correlates with the decrease or increase in the dividends.

PoS rewards are derived from a cryptocurrency protocol in an almost-standard way, while utility tokens rewards are derived from a cryptocurrencies transactional purpose.

An example is the decentralized blockchain asset exchange CryptoBridge DEX. DEX is an exchange, which means that in order to succeed as a project, DEX seeks long-term growth in terms of exchange volume: the more traders and capital are using DEX, the more transaction fees will be collected. Additionally, the team distributed an accompanying token named BridgeCoin (BCO) on the Bitshare blockchain. through a public mine over the course of six months,

By purchasing and staking BCOs on the DEX exchange, holders are rewarded to a whopping 50% of transaction fees (after-profit*). Even more interestingly, the rewards received from BridgeCoin are not paid out in BridgeCoin, but in the transaction pair that resulted in the transaction fee. If only strictly Bitcoin, Litecoin, Monero and Ethereum are traded on DEX, then the bi-weekly staking rewards would be strictly in Bitcoin, Litecoin, Monero, and Ethereum, not in BridgeCoin – a pretty nifty way to passively grow a diverse portfolio.

Dex/BCO are only one of many utility tokens such as COSS, Kucoin, who’s main business function correlates with an increase/decrease in dividends. As more blockchain teams rush to disrupt archaic business models, it’s likely a growing amount will award dividend-like financial rewards tied to their business model.

Final Thoughts: Passive, but Risky

Ultimately, the cryptocurrency space still resembles the Wild West – volatility and clickbait headlines will continue to dominate the scene for the foreseeable future. However, slowly but surely, stability will provide a pathway for passive income vehicles with growth potential, unlike the previous era of standard dividends.

For now, Proof-of-Stake, Masternodes, and a growing number of utility tokens lead the way for the first generation of passive income cryptocurrencies. Undoubtedly a few of these projects will fail, however, those that don’t will surely pay out a cushy income stream over the next decades.

The post How to Earn Passive Income with Cryptocurrencies appeared first on CoinCentral.

A blockchain, as a purveyor of this site you already likely know, is an immutable, distributed database; each new “block” of data is confirmed to be truthful by some method (usually a Proof of Something) by a majority or measured minority. Almost all blockchain blocks contain primarily a batch of transactions that represent an exchange of that chains associated cryptocurrency.

For example, the latest block committed to the Ethereum blockchain, contains a rich plethora of data within the block such as the block height, the number of transactions confirmed within the block, transaction hashes for all the transactions confirmed, the total value of ether exchanged within the block, the total value of gas & fees within the block & the reward for mining the block.

In short, there’s a trove of beautiful blockchain data that naturally exists within each blockchain project. Ask almost any enthusiast for a price tracker or mock portfolio & you’ll find yourself in a deluge of .io’s & .co’s; but ask any crypto enthusiast where they can find all the newest transactions confirmed in the latest Bitcoin block, and you’re sure to receive a blank stare.

To be fair, understanding this data is hard, seeking it out and understanding it, is well, even harder. Thankfully, a new class of websites & apps are breaking into the crypto scene that make exploring blockchain significantly more intuitive.

Enter Block Explorers

A blockchain explorer is simply a web or mobile app as we know it that directly interfaces with the data contained on a blockchain. That’s it in a nutshell. In fact, you’ve probably stumbled your way into one of the popular block explorers while surfing the crypto-web without really understand the depth of the tools at your disposal:

https://blockexplorer.com/

https://longhorn.bullpay.com/

https://www.etherchain.org/

https://live.blockcypher.com/btc/

https://etherscan.io/

We’ll go through an Etherscan example later at length; for the most part, these block explorers have common core features with very similar interfaces.

Block Explorers Common Features

A Block Explorer is basically a search platform that allows users to easily lookup blocks, transactions, smart contracts, and pretty much every data point in between for a specific blockchain.

Blockchain-Block Updates

Almost every blockchain explorer will have a constantly updating feed of blocks for their main page. The Blockchain.info & Etherscan.io websites have a stream of the latest Bitcoin & Ethereum blocks published, respectively, on their individual chains. I’ve highlighted both interfaces below in red:

The most basic feature of a cryptocurrency block explorer is that it shows the latest blocks in the blockchain per the images above. Each row represents a block & without clicking in, we can already see a substantial amount of detailed information about each specific block. The Blockchain.info BTC & Etherscan ETH block explorers both offer the following data from this row representation:

• Block Height – the order number of this specific block (remember, a blockchain starts with an origin block, block 0)
• Block Age – the amount of time that has passed since the specific block was published to the blockchain
• # of Transactions – the number of confirmed transactions that are now part of a blockchain’s history
• Relayed By / Mined By – the name of the mining pool or entity that published said last block to the blockchain

All block explorers should list new blocks the second they’re generated in their respective chains. As you can see, we’re already diving a bit deeper into the raw data outputted by cryptocurrency blockchains; but this is only the beginning, clicking on a row (block) on either Blockchain.info or Etherscan.io reveal substantially more data about that block.

Blockchain-Block Updates

Clicking on a specific network block reveals significantly more data. Again, below we use our two favorites block explorers assuming the user has now clicked on a block preview from the landing page:

Both screenshots above show the actual data stored within each block in the Bitcoin & Ethereum blockchain respectively. First, you’ll find that all of the data points that we saw in the previous views show up here as well, including height, & age.

However, we also find significantly more data than available to us before. We’re now getting into the neck of the woods in terms of raw blockchain data. Some of the more fascinating additional points seen above are:

• Hash: the unique identifier that’s a result of a confirmation algorithm such as SHA256 & a previous block hash
• Transaction Fee / Gas Used: the total amount of transactions fees in a Bitcoin block or gas in an Ethereum block
• Transaction Hashes: the unique identifier for each individual transaction that was confirmed within each block

We’re now deep under the hood of the blockchain world by reading the raw data contained within each block. As you’ve probably deduced, since block explorers provide us with individual transactions hashes, they also allow us to explore these individual transactions at a deeper length.

Depending on which block explorer one uses, there are some additional features to be enjoyed as well. Blockchain.info, for example, has become much more than just a block explorer, as it also provides statistics and charts pertaining to the bitcoin network.

Even though the name “block explorer” would suggest it can only be used to look up individual network blocks, that is not the case. Block explorers can also search for transaction IDs and wallet addresses, making them quite a nifty tool to check on specific transactions to your own wallet address. A block explorer quickly becomes a tool everyone in the cryptocurrency relies on virtually every day, yet they are far more versatile than people anticipate.

The post What’s In A Block, Anyway? | An Introduction to Block Explorers appeared first on CoinCentral.

But Bitcoin isn’t turing-complete & doesn’t have smart contracts?

No matter. Due to brilliant off-chain implementations via the Lightning Network, the day has arrived where the Bitcoin blockchain supports “decentralized apps;” this is due mainly to the innate infrastructure of multi-signature, off-chain transactions through LN’s payment channels.

A payment channel is a bi-directional, off-chain connection between exactly two nodes (users/parties) that allows for lightning-fast (thus the name), transactions. Once both nodes, or users, close the channel, the final balance is mined & all that’s added to the Bitcoin blockchain is a single transaction with two signatures.

A single node, however, can have multiple of these two-way channels open at any time. Additionally, logic can be introduced on top of a single node, making said node known for hosting payment channel to create a type of automatable service or game. An image below shows all LN nodes as of Thursday, September 13th at 5:08 pm:

LApps Overview

The fact that Lightning Network apps (“LApps”)  are now available on the Bitcoin blockchain address two noticeable common points of discussion. First, it’s no small secret that a lack of  “decentralized apps” within the Bitcoin ecosystem is one of, if not the, loudest criticisms against Bitcoin.

In fact, in many cases, it’s the single reason Ethereum, Lisk, Cardano & a plethora of blockchain platforms exist in the first place: to create & offer a blockchain-based smart contract & decentralized app environment. Suddenly, Bitcoin is quietly but quite literally closing in on the single-largest supposed competitive advantage.

What does this mean for Bitcoin? Massive incoming adoption on multiple fronts: incoming blockchain developers, current Bitcoin hodlers & possibly other platform blockchain veterans. At a point in the not-too-distant future, it is an unlikely, but now possibly scenario that a majority of current dapp & smart contract engineers abandon their current blockchain of choice for the soundest of them all. Only time will tell; however, for now, no noticeable development communities have shifted sides.

Additionally, a second major benefit of LApps is that since they’re built on the lightning network, they’re inherently structured for micro-transactions. Microtransactions drastically lower the barrier to entry; which again solidifies the notion that LApps are going to see a major influx of users & developers in the near future.

The current use cases for end users in Bitcoin world are, well, quite limited to financial activities; funding/managing wallets & exchanges. Not only does LN widen that variety, it packs a double-punch by focusing in on affordable experiences.

The real question regarding adaptability will ultimately stem, per usual, from the actual engineering output: how many LApps are in production?

LApps Directory

LApps are very much in their early days. The unofficial launch happening over Q1 this year as Blockstream introduced the micropayment processing API, Lightning Charge for the Lightning Network that utilizes Blockstream’s c-lightning implementation. Using a REST API that is accessible through JavaScript and PHP libraries, Lightning Charge makes it easy for web developers to accept Lightning payments for their content, goods, and services. In addition to Lightning Charge, a Scala implementation of LN also supports LAapps (more on this later).

Despite the relatively recent origins,  a solid number of LApps have already been publicly deployed; all released LApps can be found in the official Lightning App Directory.  Blockstream, the Bitcoin consulting behemoth with a significant amount of Bitcoin Core developers, quite publicly came out in support of LApps. In the latter half of March, Blockstream held a “Week of LApps” event dedicated strictly to the development & deployment of LApps. This intermittent development event alone resulted in seven LApps deployed – some of which are covered below. A qualitative, rudimentary categorization of public LApps, along with a few linked demo summaries can be see below:

Point-of-Sale & Vendor LApps

Accepting Bitcoin payments is a no-brainer for e-commerce platforms or custom web apps – however high fees & unpredictable confirmation periods previously made accepting Bitcoin an evangelical business decision at best. With LApps leveraging the Lightning Network, suddenly the two largest objections against Bitcoin adoption from an online business dissipate. It therefore follows that point-of-sale & vendor apps have taken the center stage as LApps begin rolling out:

• Nanopos — A simple point-of-sale system for fixed-price goods
• WooCommerce Lightning Gateway — A comprehensive e-commerce application that integrates with stock-management and order-tracking systems

Content Creator LApps

A common use case for additional blockchain & supplementary tokens is the publishing, managing, & licensing of original digital content. How many dapps fall into this category? One doesn’t have to look too far to find a blockchain/token for publishing blog posts, tracking music metadata, or managing illustration artwork. Theoretically, any, original content medium likely has a launched (or failed) decentralized app. LApps undoubtedly unlock almost-free, frictionless payments with the largest cryptocurrency of them all – but without a standard form for digital tokenization, does the same level of incorrigible asset-tracking exist for content creating LApps?

Below are a few example of content-creating web apps built on top of the mainnet lightning network:

• FileBazaar — A system for selling files such as documents, images, and videos
• Lightning Publisher for WordPress — A patronage model for unlocking WordPress blog entries

Experimental-Recreational LApps

This third category of LApps represents experimental LApps that are mainly examples of existing technologies with lightning payments enabled. Let’s recall that the Lightning Network doesn’t necessarily enable decentralization as much as they enable frictionless Bitcoin payments – which certainly unlocks a vast amount of use cases previously economically infeasible to test out.

• Lightning Jukebox — A fun demo that reimagines a classic technology for the Lightning Network
• Nanotip — The simple tip jar, rebuilt to issue Lightning Network invoices

As seen above, a handful of minimal viable LApps are now live spanning across multiple use cases. The LApp ecosystem, while now publicly in-use, is admittedly still in its infancy stage – this does not take away from the extraordinary leap forward for Bitcoin that is the Lightning Network. Other blockchain platforms have beaten Bitcoin to the punch (particularly Ethereum’s ERC20 ecosystem), it’s likely that we see developers build copy-cat LApps of popular dapps – perhaps an equivalent CryptoKitties? Or a prediction marketplace to compete with Augur?

In order to catch up with the aforementioned examples, much work is needed. For now, no off-chain LN solution exists for tokenizing standards such as ERC20 or NEO5. Without digitizing assets through tokens (forget ICOs), can LApps really directly compete with decentralized apps?

Currently, two of the many LN implementations are seeing the majority of LApp activity. First, Eclair, which is a Scala implementation of the Lightning Network built by ACINQ. Eclair hosts four LApps including the flagship Eclair desktop app. Second, is the more popular LN implementation C-Lightning, which is, as the name suggests, a “C” implementation. C-Lightning LApps are built on the C implementation of the Lightning Network, they fall under the Elements Project.

Summary

As one can see in any explorer, the Lightning Network is very much no longer in it’s theoretical or even alphas-stage – this is a successful, exponentially growing, off-chain Bitcoin solution. Unfortunately, no tool exists within the Lightning ecosystem that tracks the adoption of specifically LApp nodes within the Lightning Network mainnet; but I”m sure someone is working on that as I finish this article out, the LN ecosystem, is after all, evolving at lightning speeds.

A colleague of mine posed the question “why build with Solidity on the Ethereum Virtual Machine while a regular web stack with Ubuntu hosting a Lightning Network LApp node can offer a competing, perhaps even better, end user experience?” While I remain neutral in LApps & dapps directly competing until/if the LN ecosystem accounts for tokenizing assets, the latter half of that quote highlights what developers should keep in mind as both ecosystems mature.

The early & late majority of decentralized app adopters will not care whether their transactions are off-chain, out-chain, confirmed in multi-verses, hashed with Musk1024 or anything else – they simply want the smoother UX experience enabled with this supposed blockchain thing that uses the frictionless, magical digital money.

The post An Introduction to Lightning Network Apps (LAPPs): Scaling Bitcoin appeared first on CoinCentral.

Is there any one language used specifically for blockchains?

I don’t know how to program – can I jump straight into blockchain programming?

A few months ago, I had the pleasure of moderating a panel of four active NEO programmers at the San Francisco NEO Dev Conference. The topic of the panel was general blockchain programming, however, an additional caveat made this particular panel of participants very interesting: all four programmers wielded a different language of choice for working on the NEO project.

One favored the old-school C # language, another produced Python scripts, a third evangelized the ever-popular Javascript implementation & the fourth participant excitedly discussed an upcoming domain-specific NEO language.

Two thoughts stuck with me post-panel:

1. The NEO compiler has serious multi-language development support
2. The learning curve for blockchain programming is brutal and heavily exasperated by a lack of organized resources, especially for new developers

This article aims to address point number 2. Maximizing the effectiveness of this guide requires curtailing the expected audience to a narrow niche: new & junior programmers looking to break specifically into the blockchain space. For veteran developers, programmers, & software engineers perusing — the following section may provide some benefit, however, you’ll likely find them elementary. Senior engineers can maximize their time by scrolling to a familiar language of choice, & beginning to rip apart the attached learning resources & documentation.

So you think you’d like to break into blockchain programming eh? Let’s start by further defining exactly what blockchain programming entails.

New Industry

In general, topics that personally interest you & align with your values are easier to learn than rote memorize-ing something without a clear buy-in; I highly stress that this principle applies increasingly more in an innately-complex, rapidly-evolving field such as blockchain programming. Before we begin, let’s check out some of the challenges that a blockchain developer faces in the burgeoning industry.

First & foremost is the continual, public discrepancy between what exactly a “blockchain” does or does not entail. Spend some time in crypto-twitter & it’ll become clear just how tribal crypto -communities, & by a stretch, their development communities have become. Unchecked tribalism naturally leads to biased conversations on what ought-to-be objective content, adding another layer of obfuscation for incoming developers.

Next, with the majority of projects in their testnet phase & with live projects continuously updating, forking, & falling victim to hacks, it’s unsurprising to see incomplete documentation & unfinished tutorials. The lay of the land is rapidly evolving which requires consistent iteration – no easy task for any team.

Last is the true stigma that blockchain programming is flat-out complicated & made up of multiple intersecting fields that require at least a rudimentary understanding of the following: economics, cryptography, currency, data structures, financial policy & physics. Learning even just the parts of these fields relevant to blockchain programming takes ample time to understand — no shortcuts here.

Tribalism, haphazard documentation & complicated fundamentals. All warning signs of a steep climb up ahead. In order to adequately motivate oneself through these barriers to entry, it helps to dig through some clarity on what exactly blockchain programming means in the first place. Additionally, it might help to uncover…

Why do you want to learn blockchain programming? What project do you want specifically work on? What problem(s) are you trying to solve?

Deconstructing Blockchain Programming

If you already know what project you feverishly want to work on, kudos — I suggest heading over to the organizations GitHub repository or ctrl-Fing the language of choice here to read ahead. The following section will most benefit those that can’t quite pinpoint exactly what project & required skillset/language suits them best as a jump-off point for the potential learning roadmaps ahead.

Generally, blockchain programming can mean three different things:

• Deploying an initial coin offering (ICO)
• Building a smart contract or decentralized app (DAPP)
• Contributing to an existing or deploying a new blockchain

Strongly consider the three options described above as they each offer an array of different languages & learning curves. Additionally, they should help get you one step closer to clarifying your exact preference. Further segmentation for language criteria is right around the corner; however, don’t forget that personal preference trumps all for motivating yourself through learning a new skill.

Assuming a day-one software engineer is equally interested in learning about all three types of blockchain programming – what other criteria can they turn to in order to shine on a light on the friendliest path forward?

• General-Purpose vs Domain-Specific Languages
• Syntax Readability & Learning Curve

By overviewing these three criteria we’ll finally have a solid frame of context from which we’ll apply to our list of languages.

General-Purpose vs Domain-Specific

Categorizing tools across qualitative qualities is rarely clear-cut — programming languages are no different. Here, we’ll split all possible blockchain programming languages to two different categories: domain-specific languages & general-purpose languages.

Typically, a domain-specific language (DSL) is a computer language designed & specifically suited for a particular application. A general-purpose language (GPL), as the name aptly-describes, is a language that is broadly applicable across many programming domains.

General-Purpose Language

General-purpose languages are the languages you’ve likely heard of such as Java, Javascript, Ruby, C++, & Python. Among the general-purpose languages, one can find infinite ways to further categorize them by qualitative & quantitative differences & similarities such as readability, compiling, strictly-typed, frontend/backend, etc… A good rule of thumb on first-time friendliness is as follows:

Javascript, Python, & Ruby are generally easier for newcomers as they have less of a learning curve while C++ & Java usually take more time to learn out of the box.

Note, the editor is refraining from commenting on second & third-level consequences of a newcomer starting off with one group of languages or the other. There are multiple debates across further features of these languages, such as forcing newcomers to understand variable types first through a strictly-typed language that we’re circumventing to maximize usage here for a new developer approaching strictly the blockchain space.

The biggest pro for newcomers picking up a general-purpose is the immediate ability to apply that language in a vast number of fields outside of blockchain programming. Unfortunately, the flipside of that same coin creates a con for those newcomers looking to join the job market as you’ll likely compete directly against senior & veteran software engineers from other domains with years of experience wielding said general-purpose language.

Domain-Specific Language

To provide context, let’s step back from blockchain programming. While it’s a fairly new programming field, the concept of a new programming field itself is not that new – you don’t have to look too far past the twin-recent-buzzword machine learning to see this. A few, additional programming field that has also witnessed a natural evolution of one or more domain-specific languages are: statistics (R, MatLab), database querying (SQL), Web UI (HTML, CSS).

Domain-specific language blockchain programmers are in very high demand with very little supply: these young languages, whose only purpose is one or more of the three blockchain programming options listed above, undoubtedly offer the clearest path to landing career-industry placement.

Since these languages were designed from the ground up with blockchain & smart contract engineering in mind, experienced developers may struggle to readjust previous frames of references from other languages.

While newcomers, with a fresh slate programming habits, lean-out all that’s necessary to begin deploying code in current or future projects.

Again, by circumventing the very-real programming fundamentals found in general-purpose language, one may find him or herself at a significant disadvantage down the line if the domain-specific language of his or her choice is somehow deprecated.

The follow diagram breaks down the pool of possible blockchain programming entry-points from a DSL/GDL segmentation; transparent/distant languages are languages not covered at length:

Syntax Readability & Learning Curve

Different programming languages offer different levels of readability based on how simple or complex their syntax is. Syntax refers to the designated spelling & grammar rules of a programming language. Usually, syntax readability correlates with the steepness of the learning curve; hard to read code makes for hard to learn code. Again, there are certainly exceptions to this rule however, for our purpose this linear relationship holds true.

We will use two key, yet common, programming language syntax features to create a readability understanding specifically for new developers & blockchain programming languages. The most common of these concepts is loose vs. strict variable typing.

Loose vs Strict Typing

All programming extensively uses variables; however, there isn’t simply a single, regular variable type — there are many, each with unique properties. You’ve probably heard a few of these variable types such as strings, integers, & booleans. Every programming language leverages these natural types in their syntax; however, each language layers these variable types with their own variable-referencing logic. Some languages, such as Python & Javascript, allow developers to simply use a single “var” variable: var example = “coincentral.” This flexibility allows developers to circumvent the tedious process of making sure each variable type is appropriately set in every line. Languages that hide low-level variable assigning are known as loosely-typed languages.

The latter category, strictly-typed languages, consists of a more verbose, albeit more descriptive syntax. Declaring variables in strictly-typed languages consists of specifically declaring the original variable type the developer intends to use: string example = “coincentral.” If you compare this to the previous variable declaration, pay close attention to the bolded “string.” This strict-typing of a variable is the key difference in syntax between loosely-typed language & strictly-typed language. The difference in syntax is not at all narrowed down to just declaring variables, it’s a key language design feature that’s pervasive across the entirety of each language.

Both loosely-typed & strictly-typed languages offer heaps of pros & cons tradeoffs. One of the most important trade-offs to consider for newcomers is the learning curve associated with both types. In general, loosely-typed languages offer a friendlier-syntax for newcomers & therefore a lower barrier to entry; however, the biggest immediate drawback to consider is a serious gap of fundamental software engineering knowledge when it comes to interacting with variable types.

Leverage this information however you see fit, we visually separate our pool of blockchain programming languages by loosely-typed & strictly-typed syntax below:

The Language Landscape

We’re finally at the core section of this article, which is a high-level catalog & survey of available blockchain programming languages. For each section we’ll briefly introduce the language, summarize its intended purpose within the blockchain environment, overview any projects or frameworks currently in production, & finally list out learning resources for further information.

C++

Let’s kick off with the oldest language in the list first: C++. Introduced first by one Mr.Bjarne Stroustrup in 1985, C++ was created as an extension of the original C language. The idea was to maintain the flexibility, security & efficiency of C, but to streamline the language for more object-oriented processes. Thus, leading to C++ being an object-oriented language while C remains process oriented.

C++ is a particularly powerful, oldschool, domain-general language that’s quite popular for core blockchain programming.

However, the new developer be warned. As a strictly-typed language with a relatively outdated syntax relative to its peers, the learning curve is very steep. It’s likely the hardest to language for a new developer to jump into; yet it must be stated that the fundamental knowledge attained through pushing the C++ learning curve is second-to-none. As previously stated, the blockchain world heavily leans on C++ so you’ll find no shortage of learning resources:

Bitcoin Core: https://github.com/bitcoin/bitcoin

Ripple Daemon: https://github.com/ripple/rippled

C++ Tutorial: https://www.cplusplus.com/doc/tutorial/

Javascript

JavaScript is a loosely-typed, scripting programming language for the web supported by all major browsers; it is the primary language used to enhance static HTML & CSS pages to full-fledged UIs. A few of these common web UIs include animations, refreshing pages, user menus & dialog boxes, interactive maps, etc…

This language powering all webpage behaviors in modern browsers, Javascript, was never supposed to leave the highest-level presentation layer of a web app. Yet it’s undeniable that Javascript took off, especially for newcomers, in an unprecedented way.  With Node.JS first placing Javascript server-side, then Angular/React/Vue basically rewriting the HTML/CSS stack client-side, full-stack Javascript has become all the rage. Without delving too deeply it’s safe to say at least a handful of veteran developers will groan at this recommendation. While there may be some merit to these complaints it doesn’t render the following sentence false:

Javascript is very newcomer-friendly, maturing, & now entrenched in all parts of the modern web stack.

For Javascript, the forefront runner in blockchain support is the Lisk blockchain project. Their landing page speaks volume in terms of their belief in building an entire blockchain ecosystem in Javascript: “Lisk makes it easy for developers to build and deploy blockchain applications in JavaScript.”

Learning Resources

Lisk: https://lisk.io/

Python

A relatively-modern programming language, Python is often the favorite for newcomers – and for good reason! Python was designed by Guido van Rossum with syntax simplicity & readability above all else. Since it’s release, Python has exploded as a simple yet powerful language with massive community support leading to Python integration literally everywhere – from web UI libraries such as Flask to machine learning essentials like NumPy.

While with native Python one can’t technically contribute to an existing blockchain, write decentralized apps, or hold an initial coin offering, it’d be a mistake to leave Python out of this list as almost every single blockchain ecosystem has one or more public tools written in & for Python.

Learning Resources

IBM Blockchain Foundations Tutorial – https://developer.ibm.com/courses/all/ibm-blockchain-foundation-developer/

Ethereum Web Wrapper – https://web3py.readthedocs.io/

GO

The GO (short for GOLang) programming language is a relatively modern domain-general language developed at Google in 2007 & unveiled for public use in 2012. Designed as a robust, multi-purpose language, GO was an attempt at combining the syntax & user-friendliness of modern languages such as Python & Javascript, with the performance & security advantages of older, compiled languages such as C.

GO is a compiled language – which means it runs directly within an operating system. This feature allows maximal flexibility when it comes to using GO for multiple parts of a blockchain project. Want to contribute directly to an existing blockchain? Ethereum has a protocol SDK written in GO. Want to write a smart contract? The Linux-Foundation Hyperledger Fabric blockchain has that covered.

Learning Resources

Go Documentation – https://golang.org/doc/

Go Ethereum – https://github.com/ethereum/go-ethereum

Hyperledger Fabric – https://github.com/hyperledger/fabric-sdk-go

Solidity

Solidity is a javascript-like domain-specific language made by the Ethereum team(Gavin Wood, Christian Reitwiessner, Alex Beregszaszi, Yoichi Hirai & others) for creating decentralized apps on the Ethereum platform. It’s by far the most adapted & mainstream DSL that has seen ample adoption within the Ethereum community & blockchain industry.

For anyone looking to build a dApp or hold an ICO, Solidity is hands-down one of the most straightforward ways to dive directly into the heart of it all. Since the development of Solidity began prior to the Ethereum hard-fork, it thankfully averted any engineering effects on part of the civil disagreement, as evidenced by both Ethereum Classic & Ethereum continuing Solidity support. Furthermore, the Cardano team also recently announced Solidity support – making Solidity the single blockchain programming DSL supported in multiple blockchains.

The language itself was created with developer-adoption prioritized, which led to a syntax purposefully similar to the ever-popular Javascript with, of course, a few twists.

Learning Resources

Consensys Academy – https://consensys.net/academy/

Solidity Documentation – https://solidity.readthedocs.io/en/v0.4.24/

In Closing

Bitcoin & blockchain technology will continue to revolutionize the way data & assets are transferred — it’s clear that the impact will be global & industry-agnostic. No matter where you start, taking the first step in learning one of these languages is already a substantial first step. The mismatch in supply-demand for this skillset cannot be overstated.

Best estimates place the number of active developers worldwide, at around ~20M. Yet industry estimates state that less than 1 in a whopping 1000 active developers feel confident in their skillset to consider themselves blockchain programmers & are actively applying to open positions. For the less-arithmetically inclined, that means there are roughly around 20 thousand blockchain programmers.

If that seems like a lot let’s look at Microsoft – with a headcount of roughly 100k – let’s assume they have at least one support staff per software engineer, that leaves us with around 50 thousand programmers. On the flip-side, banking giant Goldman Sachs currently staffs ~9 thousand programmers & engineers.

The point is–this shortage of blockchain programmers is very real & the answer to your inner-dialogue but is it too late for me to start learning from scratch? is NO. For developers, investors, & regulators, and everyone else involved it’s still very early days.

The only question is what project do you want to start working on & what problem do you want to start solving?

The post The Ultimate Guide to Blockchain Programming for New Developers appeared first on CoinCentral.

The word “cryptocurrency,” while originally accurate for Bitcoin, is now approaching the status of a confusing misnomer.

The now-blanket term is causing damage to the industry by providing an artificial barrier to entry with knowledge that flat out isn’t accurate. Upon hearing the term, most people, “cryptocurrency” immediately begin associating & defining blockchain-based projects with qualities of fiat currencies. It’s imperative that we (as a community) make it clear to new entrants what exactly constitutes a “cryptocurrency” — or at the very least point them in the direction of a few frameworks.

The early 2018 bear market makes for the perfect moment to pause the frenzy, take a few steps back, & re-visit terms that as an industry we’ve coined that ultimately confuse & mislead the hell out of new entrants.

Rampant, ignorant price speculation diminishes the perceived value of slowing down, reading white papers, & technically digesting the burgeoning industry.

Let’s mature as an industry. In order to make a tangible step towards this, let’s fix what is clearly a glaring sign of disorganization & highly-confusing barrier to entry for newcomers: the definition & classification of tokenized digital assets known collectively as cryptocurrencies.

The goal for the initiative behind this categorization is to inspire those with more expertise to come along and build on top of the knowledge framework we’re developing today.

Existing Frameworks

We’re not the very first to point out the need for a classification framework.

We’re more so putting forth a summary of these previous attempts with an end goal of starting a dialogue. As an industry, it’s critical that we come to a consensus on a framework. Thankfully, we won’t be starting from ground-zero as a few innovators have put forth frameworks that we’ll quickly summarize.

Angus Cepka’s Six Tiered Framework

First off, a big thanks to Angus Cepka, an associate at Goldman Sachs, for his six-tiered framework. He diligently summarized two other previous frameworks to derive his own. He defines each category succinctly, so we’ll list out his framework along with a defining sentence:

1. Cryptocurrencies: This type of digital currency is designed to be a replacement for money and is most likely to be used on a transactional basis.

2. Platforms: This type digital assets main utility is to be used as ‘gas/fuel’ for a blockchain platform that has decentralized applications built on top.

3. Utility Tokens: These coins are required to perform a specific action in an ecosystem run by the coin issuer. They are generally built on top of an existing blockchain such as Ethereum.

4. Tokenized Real Assets: A cryptosecurity would represent equity, but be built on the blockchain and tokenized.

5. Cryptosecurity: This type of asset acts much like a traditional security; a token of this type often comes with dividend payouts and voting rights.

6. Hybrids: There are many digital assets which have characteristics that don’t place them neatly within a single category.

Phil Glazer’s Three-Tier Framework

Next, we have Phil Glazer, from the Maschmeyer Venture Group, who put forth a relatively simple three-tier framework. I’ll save my reasoning for a later paragraph, but I’m quickly glossing over the three-tier frameworks to compare, contrast & discuss them at length, so don’t worry, we’ll expand on the following list shortly:

1. Currency
2. Utility
3. Platform

Lou Kerner’s Three-Tier Framework

Lou Kerner, a partner at CryptoOracle VC, along with Geektime hosted a 400-thought leader conference call where they discussed, among many things, a classification framework. They also proposed a three-tiered classification system:

1. Crypto-currencies
2. Utility Tokens
3. Crypto-securities

David Goodboy’s Three-Tier Framework

From an op-ed on NasDaq by one David Goodboy, we have another relatively simple three-tier framework:

1. Transactional
2. Utility
3. Platform

Okex’s Seven-Tier Framework

Okex, a cryptocurrency exchange, also put together a classification framework consisting of seven different categories:

1. Currency: The purpose is to develop a better currency for a wide range of use case scenarios including as a tool to store value, a medium of value exchange and as an accounting unit.

2. Developer Tools: Projects belonging to this category are mainly used by developers as modules for building decentralized applications.

3. FinTech: [These projects] have the purpose of acting as new crypto-economy tools such as converting one currency unit into another, facilitating lending, accepting investment, & so on.

4. Sovereignty: Projects aiming to provide solutions so that might never have to rely on any individual or organization to facilitate trust, such as cloud-based computing

5. Shared Data: The goal is to allow anyone to contribute and share, annotate and create different analytical models on certain data sets.

6. Authenticity: Projects in this category strive to provide the linkage between digital and ‘real world’ asset.  

7. Value Exchange: Projects in this category strive to replace this need for trust in traditional value exchange, leaving the middleman out and reducing the overall cost for users to exchange goods and services.

Summarizing The Summaries

A few recurring similarities & differences stood out to me while analyzing previous frameworks. The largest noticeable difference stems from the number of categories within each framework; this range varies widely from a minimalist three-tiered framework to a whopping nine-tiered framework. Interestingly, the three-tiered frameworks also heavily represent the mode number of categories among all proposed frameworks.

Three-Tiered Classification Frameworks

Exploring the most popular frameworks by number of categories, the three-tiered classifications put forward by Glazer, Kerner, & Goodboy, a few more noteworthy similarities come to light.

All three frameworks list “Utility” as one of their three basic classifications.

Unfortunately, the three definitions fail to reach a consensus past an exact overlapping nomenclature. Goodboy defines a utility cryptocurrency as a “cryptocurrency designed for a particular task.” This seems a bit too wide of a definition. Kerner & Glazer both offer deeper, more useful definitions that acknowledge a blockchain infrastructure that contains decentralized apps (dapps); however, Glazer defines a utility crypto as a crypto that “can be leveraged on top of,” while Kerner qualifies a utility token as a traded asset on a dapp that leverages an existing blockchain.

I believe that Kerner puts forward the most accurate & agreed-upon definition for a utility token — and agree that since these tokens require an existing blockchain that may already have it’s main cryptocurrency (such as Ethereum/ether & ERC20 tokens), the nomenclature token, instead of cryptocurrency fits nicely.

Next, all three frameworks dictate a type of cryptocurrency focused strictly on mainstream adoption & transactional functionality for the masses; aka, literal crypto-currencies. These cryptos are what most people, especially those new to the space, first fully understand since they can compare the word currency to a previous heuristic associated with fiat.

Both Glazer & Kerner use the literal word “cryptocurrency” while Goodboy offers “transactional.” Since we’re deriving a framework of classification for cryptocurrencies, I’d steer away from assigning one of those classifications as the very same cryptocurrency – don’t define a word by using that word in the definition right? Let’s fall back to Goodboy’s name which nicely describes the main functionality of this classification: transactional.

A final similarity, albeit more superficial via similar nomenclatures, rather than meaningful in similar definitions, can be seen by two of the three (Glazer & Goodboy)  frameworks dictating “Platform” as their third & final classification. Kerner, submits an interesting “Crypto-securities” definition as his third & final classification.

Out of these three, I believe that Glazer & Goodboy are on the right track with the nomenclature “Platform.”

From my perspective, the most important consideration for defining a “Platform” cryptocurrency is the relationship that stems from Platform cryptocurrencies & Utility tokens: utility tokens are built on top of platform cryptocurrencies. Or, at least, that makes the most intuitive sense to me.

Final Thoughts

By parsing the three-tiered frameworks we can extrapolate a pretty-agreeable average framework that categorizes “cryptocurrencies” into three overarching classes: transactional cryptocurrencies, platform cryptocurrencies, & utility tokens.

While price peaks & valleys new will undoubtedly continue to dominate the news cycle through 2018, I suggest a journalistic shift of focus for the good of the industry. Slow down. The long-lasting, impactful effects of cryptocurrencies will be felt for decades to come, so let’s take the time to ensure that we’re all on the same page this early on.

The post What’s a Cryptocurrency, Anyway? – The Art of Cryptocurrency Categorization appeared first on CoinCentral.

“Bitcoin is a superior currency because it’s open-source.”

“What do you mean the Ethereum code is public on GitHub?”

A Quick Word About Technical Terms

Blockchain/cryptocurrency projects & the ever-mysterious open-source. If you come from a nontechnical background, you’ve probably wondered just exactly what open-source means; if you’ve hung around developers, in particular, you might’ve even heard about the powerful GitHub & the world of repositories. If you aren’t familiar with a terminal console, you likely aren’t familiar with previous terms.

Yet understanding how open-source repositories work, as well as exploring the very basics of the GitHub platform, is probably one of the most effective ways to understand cryptocurrencies & their respective communities at a deeper level.

Code talks. And learning how to view the source code for cryptocurrencies projects by yourself, regardless of your programming proficiency (or lack of), is an indispensable tool.

In this article, we break down exactly what open-source means & explore how blockchain & cryptocurrency teams leverage GitHub. Throughout, we’ll break down some associated jargon, so that the next time your developer friend says “the shitcoin you told me about has literally zero commits to its repository, it’s clearly a scam”’ you’ll know exactly what it is she’s talking about.

Open-Source

An open-source software(blockchain) project is a software project with source code that anyone can inspect, modify, & enhance. The world of open-source software projects expand far past the world of blockchains(Hi Linux!), however, the majority of all blockchains are open-source by design.

In contrast, the majority of software projects have source code that only the person, team, or organization who created it maintains exclusive control over it. Think Facebook, Adobe & other private company behemoths. This is called proprietary software or closed-source software because only the original authors of proprietary software can legally access, copy & alter said software.

Open-source software makes its source available to the public domain – for all to view, copy, alter, learn from & share. By design, open source software promotes collaboration, merit, & sharing because it permits other people to make modifications to the source code, & if enough people agree, incorporate said changes to the public source code. No single person, entity or organization has exclusive or proprietary rights over an open-source project; the public domain, through a set of rules governing the project (usually called a protocol), comes to a consensus in a more decentralized manner.

By building software used globally with an open-source framework, the foundation is set for a leap forward in how large scale systems are maintained: decentralized. To qualify my statement, I’ll go ahead & preface that centralization vs. decentralization is not a binary comparison by any measure – but rather a sliding scale. You likely have a correct association with these terms already: an authoritarian government reflects a centralization of power, while a direct democracy portrays a decentralization of power.

Building blockchain projects that are primarily open-source has yielded a fascinating result: powerful decentralized software that is *not* built by a centralized system such as a government or corporation.

We could go about decentralization vs. centralization; however, for now, it’s enough to know that open-source software is one of the key drivers in this rapid expansion of decentralized everything.

GitHub

Thinking from a logistics standpoint, a decentralized software project, however decentralized, still requires a single place for all project contributors (developers) to view, alter, compare & ultimately update code. This is where GitHub comes in:

GitHub is a real-time collaboration platform for developers to simultaneously work on the same source code without overriding each other’s work.

GitHub tracks the history of changes to a project’s source code, including what specifically has been changed, who has changed what & when. A software project on GitHub is referred to as a repository. Any update to a software project is called a commit. Note, any change to a project is considered a commit, not strictly programming changes. Writing updates to the project documentation, like Vitalik does here on the Ethereum organization repository, is also considered a commit.

Before we wrap up here, I need to give the disclaimer that I’m very quickly defining GitHub for the pure purpose of exploring blockchain projects. GitHub offers much more functionally & it’s often a common misconception that GitHub is a tool strictly for developers. The further you delve into the platform, the more you’ll recognize social dynamics & resource-sharing capabilities that closely resemble that of a social network. In fact, at this very moment, GitHub’s thriving community lays claim to a whopping 12 million+ members that ”favorite” repositories they like, coment, monitor & subscribe to different authors & project repositories for updates.

Below is a screenshot of what the “home page” for each of these repositories look like.

This is the literal Bitcoin GitHub repository – where all of the source code, commits over time, open issues, & documentation lives:

Repository Navigation

For this first screenshot with the red rectangle, the navigation options within a GitHub repository. As you can see, one could explore this repository further by clicking the Issues, Pull Requests, Projects or Insights tab.

The Issues section in particular is a fascinating subsection of a repository that display the most accurate, pressing issues for the repository community. Reading through these open issues is a phenomenal way to understand the immediate roadmap for open-source projects without any journalistic bias – code talks.

Source Code Metrics

Screenshot numero dos above highlights key metrics for the overall Bitcoin repository. Every repository on GitHub tracks & displays the following four figures: commits, branches, releases & contributors.

We discussed commits above – any change, documentation or code, that’s been accepted into the main repository. As you can see, at a whopping 17K commits, the Bitcoin repository is quite active. Additionally, one can review the actual people working on this repository by clicking on the “contributors” section.

A contributor to a repository is an individual who has successfully committed changes that have been accepted by the repository community & merged into the source code.

These are the individuals that one should turn to for project updates; contributors are the real deal, those working towards building these colossal projects.

Summarizing

Navigating through GitHub repositories is the best way to see first-hand the latest progress & source code for blockchain projects. Ultimately, these crypto & blockchain projects were built specifically with a distributed/decentralized infrastructure for a reason: to push forward an open-source community mindset. So now you know. The next time you’re exploring the latest coin of the week, come read the summary here first, but then head right to the GitHub repository to comb through the source yourself.

The post At The Source, Exploring the Blockchain Realm of GitHub appeared first on CoinCentral.

With ERC20 token-based juggernauts such as EOS, Basic Attention Token (BAT), and Storj, it’s difficult to argue the interface contract’s success. The Ethereum community has clearly rallied support around this standard, & both developer communities and financial markets are responding positively. However, for all of its success the ERC20 standard has resulted in one not-so-insignificant bug:

The ERC20 token standard is leading to money losses for end users by allowing users to send ERC20 tokens to none-ERC20 compliant token addresses.

When a user sends an ERC20 token to an Ethereum contract that doesn’t recognize ERC20 tokens, the user loses access to his or her funds forever. Just exactly how many funds are currently locked due to this issue? Again, not an insignificant amount:

• 310,067 GNT are stuck in Golem contract (currently worth about $217K).
• 242 REP are stuck in Augur contract (currently worth about $15K).
• 814 DGD are stuck in Digix DAO contract (currently worth about $125K).
• 14,506 1ST are stuck in FirstBlood contract (currently worth about $12K).

This is over a whopping $370K+ of ERC20 tokens that are frozen in these contracts; since the list of ERC20 tokens is growing, this number is most likely a conservative underestimate of the total amount of these tokens frozen in contracts. The list above is by no means exhaustive — these are just a few of the more popular ERC20 tokens.

None of the contracts above ever expected to receive any ERC20 tokens — so when users send tokens to these addresses, the transactions are confirmed by the network; however, the receiving contract doesn’t recognize the tokens. It doesn’t know what to do with these tokens which results in the funds being locked forever. Again, the tokens don’t get rejected — they’re just entirely ignored by the receiving contract.

The majority of these transactions are unintentionally committed by end users calling the transfer function (as opposed to the automated transferFrom function introduced previously). Recall that ERC20 makes use of both Transfer & TransferFrom — as it turns out some end users are using Transfer to directly send ERC20 tokens to contracts that aren’t expecting, & therefore don’t recognize, the incoming tokens.

Eventually, a few members of the Ethereum community decided to tackle this issue head-on by requesting a new ERC token standard. The issue number of this new token standard on GitHub, is issue number #223.

ERC223 Proposal

GitHub user Dexaran suggested a new ERC standard (ERC223) back in March 5th, 2017 that aimed to fix this token fallback failure issue. The abstract for his GitHub issue #223 new token proposal is the following:

The following describes standard functions a token contract and contract working with the specified token can implement to prevent accidentally sends of tokens to contracts and make token transactions behave like ether transactions.

Dexaran’s token proposal implements two core features in order to immediately stop decentralized app users from accidentally sending tokens to smart contracts that aren’t ready to receive said tokens:

1. Consolidating the ERC20 Transfer & TransferFrom functions into a single Transfer function with three parameters: (address _to, uint _value, bytes data).
2. The receiving contract, if receiving tokens, must contain a TokenFallBack function that defines exactly how to handle which type of incoming token.

Transfer & TransferFrom -> Transfer

A key part of ERC20 standard that contributes to this common issue is the fact that end users have the option mistakenly use one of the two functions used to transfer (Transfer & TransferFrom).

ERC223 proposes replacing both functions with a single Transfer function.

The ERC223 allows dapp end-users to send tokens to any Ethereum address, regardless of whether that contract is a wallet or a contract, with the same Transfer function. The logic here is that by eliminating the option for users to trigger a Transfer function or a TransferFrom function to just a single Transfer function, end users no longer have the potential to use the incorrect function.

The newly proposed Transfer function accepts three parameters (previously only accepted two), and, more importantly, it looks to invoke a TokenFallback function on the receiving address. Without the three defined parameters, the Transfer function fails to compile; without the receiving address containing a TokenFallback function, the Transfer function transaction will fail & no tokens will be transferred.

function tokenFallBack()

In Ethereum development there exists a contract modifier payable that’s used to prepare a contract to receive Ether — this means a contract is now expecting the digital currency. If a contract does not contain the payable modifier, the transaction sent is simply canceled & returned. Nothing fancy, this is Ethereum 101.

An analogous way of thinking about the ERC223 tokenFallback function is that the payable modifier is to preparing a contract to receiving Ether, as the tokenFallback function is to preparing a contract to receive x token.

In this standard, contract developers must implement tokenFallback if they want their contracts to work with specific tokens. If the receiver is a non-contract address, an ERC223 token transaction will execute just like any current ERC20 token transfer. On the other hand, if the receiver is a contract, then the ERC223 token contract will first try to call tokenFallback on the receiver contract; if no tokenFallback function is found, the transaction will fail.

Evolution of ERC

Despite the rough draft state of ERC223, another ERC standard looms on the horizon — ERC 721. ERC721 focuses on non-fungible assets such as CryptoKitties, Decentraland land, & perhaps even one-day real-estate assets. ERC 721 progress can be found here: https://github.com/ethereum/eips/issues/721

All to show that while young, the Ethereum community is very serious about improving its smart contract platform by putting the right standards in front of a growing wave of new developers. Slowly but surely, ERC token bugs will decrease — and then the question will become can the latest standard scale?

The post ERC223 – Proposed ERC20 Upgrade appeared first on CoinCentral.

This article assumes the reader is already familiar with at the very least, the following concepts: the Ethereum blockchain, dapps, ether, smart contracts & ICOs.

To quickly re-cap, the Ethereum blockchain is a distributed, open-source blockchain-based computing platform. This computing platform, the Ethereum network, hosts decentralized applications (dapps) that are executed with chunks of codes named smart contracts; all transactions on the Ethereum network, as well as the computing costs of executing smart contracts, are paid for in the Ethereum cryptocurrency ether.

Some, but not all, of these dapps (decentralized apps) require an additional in-dapp currency — these dapps introduce their new currency, named token, and raise funds through an initial coin offering (ICO).

The Ethereum blockchain platform is built in such a way that it encourages dapps of all kind — including those that require the creation, maintenance & transferring of digital assets. These dapp-specific Ethereum tokens can be are implemented in order to create a network of dapps with meaningful use cases such as invoice factoring, browser-wide payments, & a cryptocurrency debit card.

All previously mentioned ideas are currently-live Ethereum based dapp-tokens that follow a very common token programming standard; in fact, 99% of all deployed Ethereum tokens follow this standard, the ERC20 standard.

The ERC20 token standard, which stands for Ethereum Requests for Comment, is a standard set of programming “rules” that all Ethereum-based token are expected to follow. Developers agreed on these six functions & two events as the minimal viable token in order to normalize expected behaviors while communicating across the Ethereum network — by establishing this protocol, Ethereum developers are able to work with external smart contracts easily.

Introducing Solidity

While the most popular Ethereum client is currently written in Google’s GO, the choices for a developer-friendly smart contract language are plentiful. Developers can choose from languages such as Vyper, Bamboo, Serpent & Solidity.

For the remainder of this article we’ll highlight & walkthrough Solidity syntax.

Solidity is a high-level contract-oriented programming language used for implementing smart contracts. The Solidity syntax, to those familiar with programming, is a mishmash of Javascript, Python, & C concepts; it’s statically-typed, supports inheritance & has a host of libraries right from the get-go. For further information on Solidity you should head over to the documentation found here: https://solidity.readthedocs.io/en/develop/#

ERC20 Interface Walkthrough

We’re going to start digging a little deeper into exactly what & how this standard is implemented across the Ethereum network — as previously mentioned, we’ll cover this specifically in Solidity syntax.

In Ethereum-land, it all starts & ends with contracts. Solidity documentation defines contracts as “a collection of code (its functions) & data (its state) that reside at a specific address on the Ethereum blockchain.” Ethereum contracts support inheritance — so a contract can be an instance of another contract.

Following this logic, an abstract contract, one that’s used strictly for inheritance, can also be used as failsafe by defining what a new contract must contain in order to compile. These abstract contracts, are also known as interface contracts.

This means that any token contract that’s an ERC20 instance does not compile without the following; in contrast, this means Ethereum developers now know what functions & behaviors they can expect when interacting with any ERC20 token.

The ERC20 standard is an interface contract that contains a grand total of six executable functions & two logging events.

Allowance

The Allowance function allows for two address to create repeated unidirectional transfer; a wallet address tokenOwner & a second wallet spender are the defined as the two wallets that will engage in repeated transactions. Specifically, the wallet spender will withdraw some amount from the wallet tokenOwner at some interval – both of these are variables that’ll be determined later on.

Approve

For the Approve function, refer back to our Allowance function: the function allows for two addresses to repeatedly withdraw unidirectionally. The Approve function, aptly named, is a simple standard function that calls for the wallet owner to “approve” a transaction that’s about to made on his/her behalf in context of an Allowance. This function requires two inputs, the address of the spender & the amount of tokens being sent. The output returns a public boolean that dictates whether approval was provided or rejected.

BalanceOf

BalanceOf is an intuitive function that accepts a single address input parameter (address tokenOwner) & returns a single public constant (uint balance). The returned uint constant, balance, represents the amount of tokens the queried address holds — remember, transactions on a blockchain are usually public, Ethereum is no different.

TotalSupply

The totalSupply function, as you can probably guess from the name, is an anonymous constructor function that’s ran only once in the very first moment of deployment to the live Ethereum network. The function returns a public constant totalSupply unassigned integer (uint) that acts as that tokens total supply for the remainder of the contracts life. This totalSupply constant is usually defined one of two ways: hardcoding a variable or funding from an origin wallet.

Transfer

The Transfer function is the core function of any ERC20 token; it defines & implements direct wallet-owner-to-peer token transferring. Since wallet owners make this call, only two parameters are required: the receiver address & the amount of tokens being sent. These two parameters are usually initialized as (address to) & (uint tokens). The Transfer return value is simply a boolean that confirms whether the receiver (the “to” address) received the tokens sent.

TransferFrom

The TransferFrom function allows for a smart contract to execute a transfer with the parameters passed on behalf of the wallet owner. Carefully make the distinction with the previous Transfer function. The previous function allowed for the wallet owner to directly send tokens to an address; this TransferFrom allows for a smart contract to send tokens on the wallet owners’ behalf, such as filling an order on an exchange, releasing funds in a timely manner, or paying our winnings in an game of luck.

The TransferFrom function has three input parameters, the address of the wallet owner, the address of the receiver wallet, & the amount of tokens sent. They’re often initialized in in the following syntax: (address from, address to, uint tokens). The function output is exactly the same as the Transfer output: a single public boolean that details the success or failure of the transaction.

Summary

The six functions detailed above are the six core functions found in 99% of all currently live ERC20 tokens. With a few exceptions (looking at you Golem), Ethereum developers can feel safe knowing they can fully expect these core functions while developing internal contracts or when interacting with external public contracts out in the wild.

The post Understanding ERC20 appeared first on CoinCentral.

A generic hash function is a special type of programming function that is used to map data of arbitrary size to data of a fixed size. Hash functions originated from a need to compress data in order to reduce the amount of memory required to store large files. The most popular use case for a hash function is for another specific data structure called a hash table, which is widely used for rapid data lookup. Hash functions help speed up a table or database lookup by detecting any two exact same hashes.

They also help minify tags for enormous files such as mp3s, PDFs or images in order to make working with these rather large file types manageable. For rapid identification, a key requirement of hash functions is that they output a fixed-length string of alphanumeric characters.

While the core reason for the inception of a hash function came from a need to compress content, a secondary benefit soon became a staple of hashing: singularly-unique identifiers. Ideally, when hashing multiple messages, no two different messages should ever return the same hash. Two different hashed messages resulting in the same output hash is called a collision.

From a database management perspective, this would mean that two different objects end up being stored in the same cell — no good if one is looking to define singularly-unique identifiers. If we consider a hash function with infinite inputs (meaning we can hash any string), we can derive just exactly why collisions are in fact unavoidable.

Pigeonhole Principle

Within cryptography math there exists a concept called the pigeonhole principle which states that if we fit (n) elements into (m) spaces where n > m, then, by principle, there exists at least one space (m) occupied by more than two elements (n).

For example, five individuals check their coats in one of three available coat cubbies. By the pigeonhole principle, since the number of coats stored (n) is greater than the available cubbies (m), it’s guaranteed that at least one cubby holds more than a single coat.

Typically software engineers are interested in hash functions with an infinite domain (that’s to say they take as input strings of all possible lengths) and a finite range. Again following the pigeonhole principle, since our range (n) is smaller than our domain (m), it follows that at least one collision must exist. An effective hash function therefore only looks to minimize the number of collisions — why this matters will become more clear in a moment, but for now, let’s go return to the history of hashes.

While hash functions originated strictly from database upkeep & management needs, which favored speed above all, their utility quickly evolved. A special branch of hash functions which favored privacy, security, & transparency soon entered the field; a branch of hash functions that will remain the focus of this article: cryptographic hashing functions.

Cryptographic Hashing

Cryptographic hashing functions, as the name aptly implies, favor the preservation of absolutely undisrupted messages. While minimizing collisions is good practice for other hash functions, for specifically cryptographic functions, minimizing collisions is a requirement. Instead of maximizing the utility for a rapid database or table lookup scenario, cryptographic hashing functions are built with an adversarial scenario in mind: one in which a code-breaker (cryptoanalyst) is actively trying to cause a collision. We’ll now define standard hash function notations & establish hash function principles within the cryptography perspective.

Hash Function Notation

A generic cryptographic hash function has two inputs: the message it’s going to compress or hash ( x) & a public key (s) that represents the fixed-length output of our hash in alphanumeric characters. Our hashed result is termed the message digest or simply digest (x*). This looks like the following:

H(s,x) = x*

Let’s gloss over this notation by walking through a real-life example hashing a string using a previously-standard hashing function named MD5. Say we want to use MD5 to hash a “Hello World!” string. We also know that by default MD5 always outputs a string of 128 bits (0’s & 1’s). This notation would look as follows:

H(128, x) = ed076287532e86365e841e92bfc50d8c

In fact, if you go ahead & try providing the MD5 hash function “Hello World!” yourself you should see the exact same resulting hash. Awesome. Now let’s move forward to setting the notation for a collision; in addition to previous variables H, s, x, & x* we now introduce a second message (x’). Numerically, a collision occurs when hashing two distinct messages (x & x’) results in the exact same message digest (x*):

If H(128,x) = H(128,x’), our hash function (H) is said to have a collision at x & x’.

We’ve now set the notation for the current hallmark standard of hash function cryptography; if an adversary can feasibly (computationally-speaking) cause a collision, a hash function is no longer considered practically secure.

Closing Thoughts Until Next Time

The last mathematical definition is where the fascinating catch-22 for hash function practicality lives. Hash functions originated from a need to compress & output standardized uniform data for storage convenience, which means they spit out pseudorandom strings of a fixed length. Yet in order to create a completely collision-resistant hash function, every single message (x) would have to have a hashed output of the same length as the input. Without hashes of a fixed length, we lose our ability to use them as a convenient data structure, yet by assigning a fixed length, we render our hash function not completely collision-free.

PS — I’m sure some of you smart cookies noticed that in our MD5 example we notated a hash function that returns a string of length 128, yet our “Hello World!” hash returned a 32 alphanumeric character string. Come back next time & we’ll go deeper into hash functions to explain where this difference stemmed.

The post Cryptocurrency Fundamentals: Hashing Basics & History appeared first on CoinCentral.

In order to understand cryptocurrencies at the protocol level, it’s imperative to understand the mathematical relationships underlying all of cryptography. One can start this journey by going all the way back to the very beginning: the birth of the bit & the evolution towards the byte.

Basic To The Basics

Half a century ago the father of the Information Age, Claude Shannon, published the now industry-revered A Mathematical Theory of Communication dissertation. That’s the name of the declassified version published publicly by the then mid-30s mathematician in 1949. The previously classified version, however, was a war-effort published by the prestigious Bell Labs named “A Mathematical Theory of Cryptography.” Many of the core principles that were published in the popular theory of communication stemmed from the secretive theory of cryptography. In fact, Shannon famously said the following regarding the intrinsic & overlapping properties of information communication theory & cryptography:

They were so close together you couldn’t separate them.

While the majority of this article will focus on what came after his “Mathematical Theory of Communication” thesis, in order to understand a certain standard, it’s imperative we go a decade back in Shannon’s career — to when he was a 28-year old graduate student at MIT. Pursuing a masters in electrical engineering, his main task was designing new electrical circuits for an early version of the computer. A mathematician at heart, recalled the abstract boolean math he learned in his undergraduate studies at the University of Michigan. Boolean math, as you probably guessed, is a branch of math that deals with true & false statements (or 0s and 1s). Boolean math, while fascinating, had few widespread applications in the mid-30s; on the other hand, electric circuit design, a modern scientific breakthrough, desperately needed a disciplined framework for further understanding.

In 1938, Shannon published his master thesis: A Symbolic Analysis of Relay & Switching Circuits. This genius thesis proved that using Boolean algebra, one could conceptually automate the arrangement of the relays in-then manual telephone exchanges. By extension, this meant that utilizing the binary properties of electric switches as logic functions, one could use boolean algebra to represent & solve any circuit designs.

This basic framework of circuit building currently underlies all modern digital computer hardware.

A decade after his initial master thesis, while crafting his piece de resistance communication & cryptography theory deep in the Bell Lab, he finally decided to name what he believed was the basic unit of all information: a binary digit, or, a bit.

From Bits To Bytes

And so sometime during the years that Shannons brilliance spanned across scientific information communication & war-time cryptography (1944–1949), the bit became the standard unit of information for all computing. Computers strictly understand 0s & 1s…so the question follows, how do we go from binary code to, say, the very same alphanumeric characters you’re reading on this screen?

Bit Notation

A single bit is only ever a zero or a one — it has only two possible states[0,1]. For two bits we get a total of four possibilities: [00, 01, 10, 11].

Following this pattern, it becomes fairly obvious that for every n bits we have 2^n possible states.

Eventually, the need for more symbols & letters, in order to make working with computers more developer-friendly, came to the forefront of computer scientists gaze: how does one build a number system, let alone an entire alphabet, from only 0s & 1s?

Hexadecimal

If you’ve ever had to customize a color online you’ve probably come across a hexadecimal string at one point or another — they usually look something like the following: #012f5b

Designers are very familiar with this numbering system because it’s the standard way to notate colors digitally. The core rule of the hexadecimal numbering system is that every character is represented by strictly one of the following sixteen values: 0–9 & A — F. The first ten integers (counting zero) plus the first six letters of the English alphabet make up the entirety of the hexadecimal numbering system. Again, a total of sixteen (16) total possible states; another way of writing 16 is 2⁴. How could we represent these possible states?

With a total of four bits: 4 bits = 2⁴ possible states

ASCII

Single digit integers & the first six letters of the English alphabet are certainly a step towards a more-friendly computer language — but is it enough? How would we, for example, denote a space? differentiate between lowercase & uppercase? Or use punctuation like an exclamation point or a question mark? No, sixteen characters wouldn’t do.  

The original version of today’s standard, ASCII, proposed a seven-bit system; however, shortly afterward, it became standard to use an extension (or derivative) version of the ASCII that called for an eight-bit standard. This standard meant that any human-readable character output by a computer could be represented by eight bits, which would translate to 2⁸ = 256 possible states! This eight-bit to alphanumeric character standard is best summarized by the table below:

Each of the 256 characters can be represented by a combination of eight bits

Bytes & Beyond

We’ve now covered the birth & pragmatism of computing with, as well as defining, bits. From there we explained how four bits (2⁴) give us our hexadecimal system & how eight bits (2⁸) give us our still-in-use extended ASCII language. We’re now going to introduce a final principle that’ll hopefully make it clear why understanding the fundamentals of bits is crucial to a thorough understanding of cryptography & by extension cryptocurrencies.

Eight bits (2⁸) is actually a super important number in not just cryptography & cryptocurrencies but in all computing. In fact, eight bits are so standard that they were given a new name to symbolize an eight-bit string: a byte. A byte is a string of eight bits: 8 bits = 1 byte.

The fact that bytes can represent a single character is a key reason why factors of eight are extremely common numbers in cryptography, such as 128, & 256 (from the famous Bitcoin consensus hashing algorithm SHA256). Intuitively understanding how to go from bits, to hexadecimal values to alphanumeric characters to bytes is going to be a core part of needed knowledge moving forward to really understanding the driving forces behind cryptocurrencies.

If you’re feeling overwhelmed, don’t worry, that’s perfectly natural when breaching such complex topics. Take a minute before moving on to Cryptographic Hash Functions. 

The post Bits & Bytes 101: An Introduction to Cryptography appeared first on CoinCentral.