In a silly (and PG-rated) rap battle, Hamilton and Satoshi argue the merits behind centralized and decentralized currencies.

Alexander Hamilton is one of America's Founding Fathers and served as our first Secretary of Treasury under George Washington. He was a lawyer, banker, and advocate of centralized control of fiscal and monetary policy.

And yes - he's the same Hamilton from the Broadway play.

Hamilton is played by EpicLloyd (of Epic Rap Battles of History fame.)

Satoshi Nakamoto is the creator of the Blockchain and of the Bitcoin cryptocurrency. Nobody knows what he looks like - or whether he's even a real person. (And yes - this is addressed in the rap battle).

Satoshi Nakamoto's Programmer Playing Card.

Nakamoto is portrayed by an unmasked TimothyDeLaGhetto.

In the 6-minute video, the rappers trade ideological blows with one another.

Hamilton brings up issues with Bitcoin's high transaction costs, scalability issues, and energy consumption.

Nakamoto raps about how untraceable cash can facilitate crime, and how the existence of giant banks can necessitate taxpayer bailouts.

Here's the full video:

And here are the full lyrics in case you don't want to be seen at your desk watching Alexander Hamilton rap with a musket in hand. (But really - you should watch it.)

[Alexander Hamilton]
Before we begin, everyone do me a favor,
And read a little thing I wrote called the Federalist Papers.
I explain how a nation’s unlikely to survive
Without a strong central government to keep it alive,
When I launched the central bank, Jefferson called me ill,
Now you have my face to thank on every ten dollar-bill.
When America was cash-strapped, I pushed past that,
Now some sicko makes crypto and our nation backtracks?

[Satoshi Nakamoto]
Decentralized currency. Yes, I invented it.
I’m sure many governments wish they had prevented it
Their national cash is how they keep control,
But freedom to the people was my ultimate goal.
Am I a pseudonym? A group of men? It doesn’t even matter.
I invented Bitcoin cause fiat is a disaster.
A man from Japan or a damn hologram?
I’m the reason open season on crypto began.

[Alexander Hamilton]
Does anybody know what this crypto-thing means?
To me, sounds like the new Get Broke Quick scheme,
A bunch of fools from across the land
Investing in something they don’t even understand,
Buying Litecoin, Dash, Bitcoin Cash,
It’s all gonna crash, and be gone in a flash.
All this unsupported money’s an irrational prank,
And I’ll be laughing all the way to my National Bank.

[Satoshi Nakamoto]
Hahahahahah, yeah dude, super funny,
As if banks these days still helped people make money.
The rich get richer and we follow like we’re all sheep,
The banks serve Wall Street, crypto serves all streets,
The interest in crypto’s on rapid ascent
What’s your current interest? Half a percent?
I’m sorry, the bank’s gone past its peak
But I want info encrypted, not hacked and leaked.

[Alexander Hamilton]
If this crypto system will be our salvation,
It needs to be centralized, needs regulation.
If our central database gets… how you say, “hacked?”
Insurance will just make a case to get your money back.
‘Cause in fact, it’s tracked, and the money leaves a trail.
Central currency is strong, cryptocurrency is frail.
Untraceable money — wow, so clever.
One typo in your address? Now it’s gone forever.

[Satoshi Nakamoto]
Crypto is frail? That’s the essence of your lesson?
Your money leaves a trail? Yeah, a trail to a recession.
A buncha rich white guys made this system.
Why would they ever change this, when It’s made them rich men!
Movie moguls fought hard against the VCR.
Horse and buggy manufacturers all hated the car.
So why would I take my advice from the banks?
I don’t need a bailout to survive. Thanks.

[Satoshi Nakamoto's backup singer]
The system is so broken.
We need that crypto token.

[Alexander Hamilton's backup singer]
The system isn’t broken.
Can we trust crypto tokens?

[Alexander Hamilton]
It’s gotta be centralized!

[Satoshi Nakamoto]
Decentralized!

[Alexander Hamilton]
Centralized!

[Satoshi Nakamoto]
Decentralized!

[Alexander Hamilton]
We need control!

[Satoshi Nakamoto]
Free enterprise!

[Debate moderator]
Bring me the facts.
Please testify.

[Satoshi Nakamoto]
Fiat's the way a government controls the populace.

[Alexander Hamilton]
Government protects its people. All of this is obvious.
They keep the peace, and so they keep control.
You want us ruled by crypto-miners no one even knows.

[Satoshi Nakamoto]
Oh, it’s that "Strong Central Government" bit again.
They protect people, but only their citizens.
Crypto has no borders, it's a true global currency.
And censorship resistance for those who need it urgently.

[Alexander Hamilton]
Banks earn trust by assuming liability.
You know a key, we know the customer explicitly.
Will the real Satoshi please stand up?
Nope, you’ll still be hiding when crypto busts.

[Satoshi Nakamoto]
You don’t need to trust the people, you just need to trust the code.
Every record’s in the network, you’re just one node.
And when you find a flaw, there’s a software update.
Now try updating cash. Go ahead, I’ll wait.

[Alexander Hamilton]
Wait? Cash works! You immediately pay.
Crypto's a far worse medium of exchange.
Can’t bitcoin the dentist, can’t bitcoin my breakfast.
Can’t even use bitcoin at bitcoin conventions.

[Satoshi Nakamoto]
No currency starts with universal adoption.
It takes time for places to make it an option.
Plus billions of people don’t have bank accounts.
No savings, no interest, no checks to bounce.

[Alexander Hamilton]
You’re saving the world? But what’s the price you’re paying?
The only change you’re creating is climate change.
Power grids spiking all across the land.
Overheated, no one needs it, hope it all is banned.

[Satoshi Nakamoto]
From the king of paper currency, the hypocrisy!
For bills and forms in triplicates, you’re killing all the trees.
Don’t like my power usage? Stop targeting my rights.
I own my purchased power and the market sets the price.

[Alexander Hamilton]
It’s gonna get real dark if this is crypto’s night.
They use your currency for crimes, that’s your kryptonite.

[Satoshi Nakamoto]
Most crime is done with Benjamins, not the blockchain.
There’s a reason most dollars carry traces of cocaine.

[Alexander Hamilton]
Where’s your proof of work? That’s pure speculation.
Those darknet black markets need more regulation.

[Satoshi Nakamoto]
The world’s fulla currencies. And this one makes it worse?
1 hundred eighty now, Bitcoin’s a hundred-eighty-first.

[Alexander Hamilton]
It’s not the currency itself, it’s the method, man.
You can’t build things that last without a central plan.

[Satoshi Nakamoto]
Crypto is a balance to the centralized model.
Cause things fall apart. The center cannot hodl.

[Alexander Hamilton]
If you end up having problems, I’ll feel bad for you, son.

[Satoshi Nakamoto]
I’ve got 99 problems but a bit ain’t one.

Maybe one of the most important qualities of a developer is the ability to pick the right tool for the right job, without hopping onto bandwagons or reinventing the wheel. This might require a bit of technology analysis, but even more, a touch of critical thinking.

Here is a review of a few exaggerated trends and underrated niceties, in different areas of the marvelous world of computer science: databases, asynchronicity, cryptocurrency, and data formats. I won't touch on the subject of REST webservices, which I already ranted about at great length.

As usual, your feedback is more than welcome if any factual errors slipped into this (not entirely unbiased) article.

Databases: NoSQL & ZODB

Few moments, in the history of computer science, were as ironically lit as the arrival of No-SQL databases, around 2009. A tidal wave struck the shores of backend development and system administration: SQL databases were too rigid, too slow, too hard to replicate.

So new projects massively ditched them in favor of key-value stores like Redis, document-oriented databases like MongoDB/CouchDB, or graph-oriented databases like Neo4j. And we must acknowledge one thing: these new databases shone in benchmarks; they shone about as much.... as would shine any SQL database dropping all its ACID constraints and query language flexibility.

But the horizon was grim for numerous programmers. They learned, the hard way, that data persistence was not a minor concern. And that they needed, for example, to explicitly activate "Write Concerns" in MongoDB, to ensure that data would not get lost before reaching disk oxide.

They learned that "eventual consistency" was a pretty word for "temporary inconsistency", opening the door to nasty, silent, hard-to-reproduce bugs in production. And that transactions - and their implicit locking - were precious features, and that mimicking them by hand, with awkward flags stuffed into documents, was all but easy and robust.

And they learned that data schemas, and referential integrity, were more than welcome to prevent databases from becoming heaps of incoherent objects. And that the lack of advanced indexing capabilities (on multiple keys, on deep document fields) in key-value stores could become quite embarrassing.

Thus, people began reinventing SQL features on top of NoSQL databases, by mimicking data schemas, foreign keys, advanced aggregation, in language-specific "ORM" libraries (mongoengine, mongoid, mongomapper...). In this context, this "Object-Relational Mapper" acronym should have, by itself, been a hint that something had gone wild.

There was something surreal in watching NoSQL databases, which were honed for specific use cases (highly replicated or heterogeneous data, capped-size collections or TTLs, pub/sub systems...), be used just to store a bunch of same-shape objects in a single server instance.

A standard SQL database would completely have done the job, and offered many more tooling options and plugins (different storage engines, Percona toolkit scripts, IDEs like HeidiSql or Mysql Workbench, DB schema migration processes integrated into web frameworks...). Even if it meant stuffing extra unstructured data into a serialized Text Field (or, nowadays, dedicated PostgreSQL Json Fields).

With time, NoSQL databases themselves improved a lot, among other things by borrowing features from the SQL world. But reinventing SQL is not an easy task. Relational databases deal with query language parsing, character sets and collations, data aggregation and conversion, transactions and isolation levels, views and query caches, triggers, embedded procedures, GIS, fine-grained permissions, replication and clustering... complex and sensitive features, driven by hundreds of settings spread on multiple levels (per database, per table, per connection).

So despite their great progress (multi-document transactions, better data aggregation, stored JavaScript functions, pluggable storage, role-based access control in MongoDB), NoSQL DBs still have trouble challenging major SQL databases, purely feature-wise.

Luckily, most projects only need a tiny subset of these SQL database features: a few schema validations, a few proper indices, and business can get rolling; so for teams lacking SQL expertise, the relative simplicity of many NoSQL DBs could indeed be, to be honest, a relevant factor.

The wave seems to have faded by now, and projects seem more inclined to combine different databases according to actual needs. They thus separate user accounts, job queues and similar caches, logging and stats data... each into the most relevant storage.

All these cited NoSQL databases, and their countless alternatives, are shining in their intended use cases. But I'd like to mention a too-little-known, too-little-used gem of the Python ecosystem. Have you already wanted to persist your data in a really, reaaaalllly easy way? Then I forward you to the ZODB. You open it like a dictionary, you push whatever data you want into it, you commit the transaction, and you're good to go.

Example of simple local ZODB instance:

from ZODB import FileStorage, DB
import transaction

storage = FileStorage.FileStorage('mydatabase.fs')
root = DB(storage).open().root()
print("ROOT:", root)
root['employees'] = ['Mary', 'Jo', 'Bob']
transaction.commit()

Graphs of data are handled gracefully (no recursion error), objects are lazily loaded on access, special "bucket tree" types are provided to browse huge amounts of data while keeping memory low, and several storage backends exist, including relstorage which leverages the power of SQL databases. Perfect, isn't it?

Alright, I'm lying, there are a few gotchas. There is no built-in indexing system (one must use Zcatalog or the likes instead). Using dedicated "persistent" types is highly advised, to automatically detect and persist mutations of objects. The overall tooling is quite limited compared to mainstream databases. And the concurrency model based on "optimistic locking" might force you, under heavy load, to retry an operation several times until it manages to get applied.

The extreme amount of integration with the Python language has an additional drawback: if you introduce breaking changes into your data model, your database might not load anymore, so you must handle schema migrations carefully.

But context is everything: ZODB is not meant for long term and interoperable data persistence, but for effortless storage of (possibly very heterogeneous) python objects. It can make long-running scripts able to resume after interruption, it can store player data of online game sessions... if you really want to store blog articles or personal accounts in ZODB, you had better limit yourself to native python types, and implement your own sanity checks. But whatever happens, do not use a very limited stdlib shelf, if you can have a nifty ZODB under the hand to store your work-in-progress data.

Asynchronicity: Asyncio, Trio and Green Threads

There has been an immemorial challenge between synchronous and asynchronous programming models, in all IO-bound programs. Kernels have provided asynchronous modes for disk operations, with more or less success (overlapped non-blocking IO on Windows, limited _iosubmit() API on Linux...).

Networking code has made the issue still more acute, with the need for huge numbers of long-term connections, each performing only minor CPU operations.

Some languages, like Erland, confronted this by being asynchronous from the start, and letting different tasks communicate by message passing (a.k.a Actor Model).

In other languages, several design patterns emerged to tackle the problem:

• callbacks
• async/await syntax
• lightweight threads

Callbacks were previously the major solution in mainstream frameworks. For example in jQuery or Twisted, the developer would provide callables as arguments or as instance methods, and these would be called on IO completion/cancellation, in a pattern called Inversion of Control. It works, for sure, but it makes program flows quite hard to predict and debug, hence the term "callback soup" often used in this context.

For the last few years, the async/await syntax has become highly trendy, especially in the Python world. But there is a problem: like Inversion of Control, it's a whole new way of programming, almost a new language. The vast amount of packages currently available, made of modules, classes and methods, just does NOT work with async/await.

Any IO, any expensive operation, hidden deep inside a subdependency, could ruin your day. So we're currently gazing at thousands of great modules being happily reimplemented, with a whole new world of bugs and missing features.

Is it all worth it? Python developers have massively jumped onto the train of the asyncio package, which has become part of the stdlib. But this technology has scary issues, like the difficulty of socket backpressure, the fragile handling of exceptions and ctrl-C, the unsafe cancellation of (leaking) tasks, and the steep learning curve of an API full of gotchas and redundant concepts. Other frameworks like Trio/Curio, seemed much more careful on these subjects.

If we have to recode tons of existing libraries, why base new versions on an engine that some developers have - not without arguments - called a dumpster fire of bad design? But the network effect is huge in such cases, and alternative async/await-based frameworks will have a hard time challenging the standard.

And what about the third pattern quoted above, lightweight threads? Long before this async/await trend, Python developers thought: we already have some perfectly fine synchronous business code, so let's change the way it is run, not the way it is written. Thus appeared lightweight threads, or "greenlets". They work like a bunch of tiny tasks scheduled on top of a few native threads, tasks which yield control to each other only when they block on IO or explicitly do so; and with much greater performance than native threads, in terms of memory usage and switching delay.

In the end, this system can quickly boost about any existing codebase so that it supports thousands of long-term concurrent tasks. And this is not an isolated mad experiment: Python lightweight threads have originally been used in Eve Online game (via Stackless Python), and have since successfully been ported to CPython (Gevent, Eventlet...) and PyPy. And they have actually existed for a long time in lots of programming languages, under different names (green processes, green threads, fibers...).

The drawbacks of this system?

• Libraries must play nice with green threads, by yielding control instead of blocking on IOs, and launching green threads instead of native threads. In python, main libraries (socket, time.sleep(), threading) are forcibly made green-friendly via monkey-patching; but compiled extensions must be especially checked, since they can bypass these patches and block on their own system calls.
• No heavy computation, or otherwise time-consuming tasks, must be performed, else all other tasks get impacted by the delay. For such needs, just delegate work to a pool of native threads (or a celery-like worker queue).

As we see, these drawbacks are similar to those of async/await, except that you almost don't have to touch the original, synchronous code. An "except" which can mean months or years of work avoided ; your CTO and CEO should be highly pleased about this.

Now, you'll sometimes hear strange rationalizations from people who ditched lightweight threads in favor of a whole async/await reimplementation. Something in the lines of "Explicit is better than implicit, and all these awaits show me exactly where my code could switch context, whereas green threads might switch discreetly if a third-party function performs any kind of IO or explicit switch".

But the thing is...

FIRST, why do you need to know at which points exactly the program will switch to another task? For all the past years, with native (preemptive) thread, a switch could happen anywhere, anytime, even right in a middle of a simple increment.

But we learned to deal with this invisible threat properly, by protecting critical sections with locks and other synchronization primitives (Recursive Locks, Event, Condition, Semaphore...), keeping a proper order when nesting locks, and using thread-safe data structures (Queues and the likes) which handle concurrency for us.

Green threads are a middle ground between (implicit) preemptive threads and (explicit) async/await, but all of these technologies had better stick to the good old way of protecting concurrent operations.

Locks can be dangerous when misused (especially since most implementations stall, instead of detecting deadlock and reporting them as exceptions), but they are cheap and robust. What is the point of attempting to do lock-less concurrency, by checking the position of each potentially switch-triggering calls, when you could anytime have to add a new operation (even a simple logging output) in the middle of your carefully crafted lock-less sequence, and thus ruin its safety?

This naive code shows how a recently added call to log_counter_value() breaks an otherwise safe asynchronous code.

async def increment_counter(counter):
     current = counter.current_value
     await log_counter_value(current)  # Unwanted context switch happens here
     counter.current_value = current + 1

SECOND, do you really have to deal with synchronization? In the web world especially, where HTTP requests are not supposed to interact, we want parallelization, not concurrency. Persistent data (and transactions) are supposed to be handled by external databases and caches, not in process memory heap.

So usual thread-safety good practices (using thread-safe initialization of the process via locks, read-only structures for global data, and read-write data only local to stack frames) are enough to make the whole system "thread/greenlet/asynctask safe".

If one day you need to implement highly concurrent algorithms inside a process, you'll choose the best tool for that, but no need for hammer-building factories if all you have to do is thrust one nail.

Money: Bitcoins & Alternatives

Let's ponder for a moment. What are the biggest challenges of our 21st century? Climate change? Tax evasion? Legitimacy of state power? So candid minds could think that energetic sobriety, financial traceability, and (really) democratic organizations, would be goals to pursue.

But a group of smart hackers decided that current moneys were a major issue, and came up with Bitcoins: energy-devouring "proof of work" system, easy anonymity of money holders, and fuzzy (for the least) governance.

With such adequation between needs and demand, it's no wonder that Bitcoins became what they became: a product of (almost) pure speculation, praised by ransomwares and miscellaneous mafias, mass-mined by factories of graphics cards, with an especially high appetite for being stolen (or lost).

This money, and its soon-emerged siblings, have a history already full of bewildering moments, with accidental chain splits, soft forks blocked for political reasons, hard forks quite arbitrarily decided by miscellaneous people (or forced by cyber attacks), and endless battles between different currencies, or different versions of the same currency (Bitcoin Core, Cash, Gold, SV...). Algorithms (cryptography, consensus, transaction code...) were praised as the foundations of a bullet-proof and self-governing system, but some actors had to hack their own users to protect them from theft, while even the so glorified "smart contracts" showed loads of scary security weaknesses, and not as many use cases as some expected.

Let's make it clear: the blockchain, a public ledger based on Merkle trees, is far from a bad idea. But when decisions are not based on the needs of society, and carefulness regarding bugs, but on ideology and greed, the outcome can be predicted. And the decline in hype is proportional to unduly invested hopes.

What is the "better" counterpart of Bitcoin, Ethereum, and the like? Lots of alternative cryptocurrencies exist, with lighter forms of authorization, with different crypto algorithms, with different privacy settings, with different adoption rates too... But if you ask me, what we would really need is "an easily traceable money for State finances and NGOs"; a public ledger designed so that any citizen could easily audit how public money is used, from the moment it's gathered via taxes and donations, to the moment it gets back into private circuits by paying goods or employee salaries. Does anything like this exist yet, anyone? Couldn't find it...

One could also mention non-cryptographic but local moneys (ex. the "Gonette" in Lyon, France), kept on parity with national moneys, which have the advantage of favoring local businesses and thus lowering the collateral damages of international trade.

Data Formats: Text and Binary

A witty passerby once defined XML as "the readability of binary data with the efficiency of text". Indeed XML parsers tend to be sluggish, and to clutter memory (when in DOM mode), compared to binary data loaders; and editing XML configurations and documents by hand is not the best user experience one might have.

We easily understand why XML, as a metalanguage allowing to create new tags and properties for all kinds of uses, needs to be so verbose. But why such enthusiasm for text-based formats, when the goal is to transmit information between servers using well-defined data types ?

Parsing HTTP payloads into an internal representation, and then parsing, for example, its JSON body, ends up adding significant overhead to webservice requests. For what gain ? Binary formats like Bson would make the serialization/deserialization much more performant; and semantically equivalent text formats could be used for debugging (auto-converted by web browser dev tools, Wireshark, CURL and the likes), and for manually crafting test payloads.

For sure, handling these dual representations of the same data would add a bit of complexity to the system, but in an era when startups love exposing webservices to thousands simultaneous clients, the performance boost can be real, with not so much effort.

Conclusion

What's the moral of all this? Always the same, "use the right tool for the right job, and beware of irrational fads". It can take lots of reading before one has a sufficient depth of view, on a specific matter, to take educated decisions; but this investment quickly pays off.

Guessing how well a framework will be supported on the long-term, or which protocol/format will win a standardization war, is a different problem, but at least we can have our opinions firmly founded, when it comes to purely technical aspects, and this is Gold.

Blockchain has a diverse set of use cases, ranging from finance to a decentralized Internet. However, most blockchain use cases can be implemented using relatively few patterns. For example, A Pattern Collection for Blockchain-based Applications provides a list of 15 Blockchain patterns.

Fine-grained patterns, such as described above, are useful. However, system design needs a much higher level of abstractions. It is useful also to have more coarse-grained macro patterns, which we call architecture patterns. This post describes four such architecture patterns.

Let’s get started. To describe patterns, I will use the template described in by Aleksandra Tešanovic in What is a Pattern?

Architecture Pattern for IAM.

Context: IAM environments include many users and service providers. IAM systems give each user an account and set of capabilities enabling users to go to service providers, demonstrate their ownership of accounts, and then receive services based on their capabilities.

Forces: Need to implement a decentralized IAM environment where a single rogue user or few users can’t significantly affect the system.

Solution: Proposed pattern candidate uses World Wide Web Consortium (W3C) DID specification and W3C Verifiable Claims specification in the following manner.

Figure 1: Blockchain-based IAM Architecture Pattern

Let’s assume Alice needs an identity (DID, which is a unique identifier). As shown by the figure for creating a new DID, Alice creates an entry in the blockchain. This entry includes a randomly generated identifier, a link to the repository with her profile data, and a hash of the profile data. The user profile contains a public key and a set of verifiable claims. The generated random identifier now becomes Alice’s DID because only she owns the private key that corresponds to the public key.

Verifiable claims are delegation tokens signed by a competent authority. The creator also records them in a blockchain together with the hash of the claim in a manner similar to the DID.

Alice obtains the verifiable claims in the first place by going to authorities. For example, the department of personal registration or equivalent is the proper authority for verifiable claims of name, address, and date of birth. Assuming authorities issue verifiable claims, Alice first demonstrates her ownership of the DID uses a challenge-response-protocol. Then she submits requests for verifiable claims for her attributes, which may, for example, include her name, address, degree, and date of birth. To update her profile data, Alice will add a new entry to the blockchain with a new hash of the profile.

In the challenge-response-protocol, the validator generates a random seed, encrypts it using Alice’s public key, and then challenges Alice to demonstrate that she has the private key by decrypting the encrypted seed. Since Alice has the private key, she must be the owner of the DID.

A different user or an organization (authenticator), Bob, who wants to identify Alice, first receives the DID from Alice, read all entries related to that DID from the blockchain, retrieve Alice’s profile data, and verify them. Bob can verify the identity of Alice (identification) again using challenge-response-protocol. Then Bob can confirm the verifiable claims and be assured that the claims about Alice are true.

We can layer most IAM use cases on top of this architecture pattern. For example, we can achieve access control either by issuing verifiable claims for actions we want users to perform or by only accepting users who have certain properties (e.g., age, job description, group membership) in their verifiable claims. An implementation may choose to cache relevant subsets of the profile data in a database to improve performance.

Architecture Pattern for Auditable History or Workspace

Context: A two or more parties perform transactions or works together, and their activities need to be recorded in an indisputable manner.

Forces: Need to implement a decentralized audit log or a workspace where a single rogue user or few users can’t significantly affect the system.

Solution: The proposed system records activities and creates entries in the blockchain for those records. The entry contains the hash of activity records, and therefore, the records can’t be disputed later.

Figure 2: Blockchain based Auditable History or Workspace Architecture Pattern

For example, let’s assume Alice wants to pay a tax. Tax Server accepts the payment application, creates a digital receipt, records its hash in the blockchain, and sends the receipt to Alice. Alice can verify the receipt by calculating the hash and checking against the value stored in the blockchain. After this, Bob can’t deny the receipt because the receipt hash and time are recorded in the blockchain.

If the activities are numerous, there may be a need to workaround blockchain performance limitations. Therefore, some implementations may record a hash of several activity records as a block instead of a single activity record.

Architecture Pattern for Registry or Marketplace

Context: A registry is a collection of data entries that can be searched and retrieved over the network. A market place is a registry that allows users to buy the services or products represented by data entries. For example, a registry may be a catalog of available APIs.

Forces: Need to implement a decentralized environment where a single rogue user or few users can’t significantly affect the system.

Solution: The proposed pattern works as follows.

Figure 3: Blockchain based Registry Architecture Pattern

Let’s first consider a registry. With the proposed architecture, when a user issues a registry update (to add or modify an entry), the client records the change in the blockchain. If data in the update is large, the blockchain record may contain a link to the data and a hash value of the data. If data stored in the registry needs to be amended, the registry client adds a new record to the blockchain with amended information.

In the diagram above, each user has a registry client running in the local machine (e.g., laptop or phone). Each registry client reads the update records from the blockchain, verifies the update data against the hash included in the records, and reconstructs the most current view of records from updates. For example, by reading blockchain records about APIs, their additions, amendments, and removals, the registry client can create a view that shows current APIs included in the registry. To avoid having to read and verify all records every time the registry is used, clients might store data in a database and index it. The client should periodically check the blockchain and update the registry.

Blockchain works well as a “service marketplace,” since the same service may be sold many times. However, due to performance limitations, blockchain-based marketplaces are not suitable for items that can be sold only once.

To illustrate, the functionality of a blockchain-based registry, let’s look at when Alice wants to subscribe to “weather news service” in the blockchain marketplace. When she submits her request, the registry creates credentials for the service and shares it with Alice. The payment may happen in one of several ways: using Bitcoins, via a smart contract where payments are made on a timely basis, or by some out-of-bound means.

Architecture Pattern for Smart Contracts and Managed Things

Under this pattern, we consider two cases. First, we consider smart contracts, and as the second, we consider a common special case of smart contracts: “Managed Things.”

Smart Contracts Pattern

Context: Multiple users want to abide by a contract, described as an executable program. Contract undergoes state transitions as per conditions defined in the contract, and at a given time, everyone can agree on the current status of the contract.

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

Solution: Smart contacts are part of blockchain technologies and supported by blockchain implementations, such as Ethereum. A contract is described using a smart contract language and distributed to all participants. As conditions defined in the contract changes, each participant executes the contract and records the current status in the blockchain using the consensus algorithm.

Managed Things Pattern

Context: We need to track the ownership of real-world smart things. Here smart things are real-world objects that are capable of running computing logic within them. The owner is allowed to control and perform actions on the real world things. Also, the owner may transfer his ownership to someone else.

Forces: need to implement an environment where a single rogue user or few users can’t significantly affect the system.

Solution: Following describes the implementation of the pattern using Car as the managed thing as an example.

Figure 4: Blockchain based Managed Things Architecture Pattern

We can implement a blockchain for a managed thing, in this case, a car, in two steps. First, the manufacturer records the DID and the public key of the owner of the car. When ownership changes, the owner adds a new record in the blockchain specifying the new owner. Second, when checking for ownership, the car first retrieves all records in the blockchain and verifies that each record is added by the owner at that time. This is done by checking the public key of the user who wrote the record against the public key included in the previous ownership record. The last owner in this valid chain is the current owner.

After determining the owner, the car logs in the current owner, Alice, by retrieving her public key and carrying out a challenge-response-protocol-based login with Alice’s phone, which has Alice’s private key.

Such a system reduces the risks associated with remotely controlled artifacts. For example, in a non-blockchain implementation, someone with access can change the ownership of your car. However, with the blockchain-based model, to remotely control the car, a would-be attacker must change the ownership record in the blockchain, which is very hard to achieve without being the owner.

However, it is hard to stop someone who has access to the “thing” from physically changing the logic running inside (e.g., by replacing the firmware of the car). One solution to this problem is to build some form of self-destruct that triggers when tampering into the artifact is detected.

For example, Alice buys the car from Bob using a smart contract that pays Bob and updates the ownership of the vehicle. After the transaction, Alice walks to the car, which reads Alice’s DID from the phone, retrieves her public key, authenticates her using a challenge-response-protocol by communicating with the phone that has Alice’s private key, verifies her ownership, and unlocks the car.

Conclusion

We discussed four blockchain based architecture patterns. The GitHub document, Blockchain-based Integration Use Cases, shows these patterns in action, describing how 30-plus blockchain use cases can be implemented using these four patterns.

If you have opinions about the above patterns or know about other patterns, I would really like to hear about them.

I hope this was useful. If you like this, you might also like a detailed blockchain analysis in our recently published paper, “A use case centric survey of Blockchain: status quo and future directions.”

We’re currently in the midst of a new burgeoning industry with blockchain development.

Blockchain technology is very much in a nascent stage, however this disruptive technology has already managed to take the world by storm and has experienced a boom like no other in recent times.

With many well-funded projects now eager to build out their blockchain network and deploy decentralized applications on top of them, there’s a great shortage of capable, competent blockchain developers.

With billions having been funneled into this sector, the pay and demand for blockchain developers has escalated with projects bidding against each other to attract the best blockchain talent that is left on the market.

This gold rush may leave some developers wondering if they have what it takes to dive into this industry, and especially what programming languages are most sought after in this new industry. Almost all popular programming languages are used in the blockchain industry, however developers have to consider what type of development they would like to undertake as different languages are used for certain blockchain projects and applications.

Here’s a brief rundown of the different languages and projects that are utilizing them to serve as a basic understanding and foundation for those looking to dive deeper into this industry.

Solidity — A new and simple programming language that is popular amongst Ethereum developers, as it is the language used for developing Ethereum smart contracts. Solidity is a contract-oriented Turing-complete programming language and the number of developers is estimated at over 200,000.

As Ethereum has taken the head start on smart contracts, many alternative blockchain platforms are ensuring that they are Solidity (or ERC-20) compatible, thus allowing smart contracts to be easily ported from Ethereum into their new blockchain networks.

Ethereum — Technically Ethereum functions as an Ethereum Virtual Machine (EVM) as a “world computer”, and is made up of multiple languages including C++, Python, Ruby, Go, and Java. JavaScript serves as the backbone of Ethereum as it functions as a runtime environment with script execution.

Java — A general-purpose programming language that is concurrent, object-oriented, and class-based is designed in such a way that Java has few implementation dependencies. Since its launch in 1995, Java has become one of the top 3 programming languages and rightly so with over 9 million developers. NEM’s core blockchain network has been written solely in Java (soon to be C++).

C# — An object-oriented language known to enable developers to build robust applications that run on the .NET Framework with at least 2M developers worldwide. C# was developed back in 2000. Since its inception, it has become a popular programming language used to build powerful cross platform code that works over multiple operating systems such as Windows, Mac, Linux, and Android. Blockchain projects written with C# include:

• Stratis a Blockchain-as-a-Service provider backed by Microsoft, allows enterprises to build their own private blockchain systems.
• NEO was written in C#, however it also supports a variety of programming languages such as Javascript, Java, Python, and Go.

Javascript — Often abbreviated as JS, this is a multi-paradigm language that supports event-driven, functional, and imperative (including object-oriented and prototype-based) programming styles. It is one of the most popular programming languages in the world used by at least 9.7M developers worldwide.

Lisk’s SideChain Development Kit (SDK) is written in JavaScript and allows developers to build applications on top of Lisk’s blockchain platform.

SQL — Structured Query Language or ‘’Sequel’’ is a programming language developed by IBM used to communicate with databases that store, query, and manipulate data. There is an estimated 7 million developers for SQL today. Popular databases such as MySQL, PostgreSQL, SQL Server, DB2, Oracle and more all use SQL to develop applications. A blockchain project that incorporates SQL is:

• Aergo — An entreprise-ready blockchain solution developed by Blocko under their proprietary Coinstack technology utilizes SQL smart contracts. The Aergo chain features a SQL-based smart contract platform that will allow enterprise entities to create and execute advanced smart contracts in commercial business environments.

C++ — A general-purpose programming language with an estimated 4.4 million developers, it’s greatest strength lies in the capability to scale resource intensive applications and enable them to run smoothly, thus making it a very popular programming language for 3D games. Blockchain projects using C++ include:

• EOS — C++ is the main programming language of EOS preferred for its flexibility to run extensive applications on top of the blockchain. EOS also supports any language that compiles into WebAssembly (WASM)

Random Fact: Bitcoin core’s network is programmed in C++.

Golang — An open source general programming language loosely based on the syntax of the C programming language, Golang is easy for developers to learn, and for testers to understand. Currently there is an estimated 800,000+ developers on the Golang language that is used by the consortium network:

• HyperLedger Fabric — Most of the chaincode (smart contracts built using HyperLedger Fabrics) is written in Golang. They also have a Java SDK for developing blockchain applications.

Hopefully this has provided you with a basic overview of where to start and what to dig into further if the blockchain industry is something that interests you. There is little doubt that this industry will continue to further explode over the next decade or so as advancements are made and real-world adoption use cases emerge.

Not everything will be tokenized, but that which can be will be.

2017 saw the hype of utility tokens and ICOs. 2018 marks the hyped start of asset tokenization and the launch of securities tokens/platforms. This trend is notably huge in the U.S, given how A16z and GGV Capital invested in the likes of tokenization platforms like TrustToken, Harbor, and Polymath.

In Asia, the trend is starting to pick up too. For instance, Rate3 Network was funded by various notable Asian VCs that include Matrix Partners China and Fenbushi Capital.

Conceptually, tokenization might seem easy: Issue an ERC-20 token (or any other blockchain tokens), imbue legal rights and ownership rights in the tokens, and you can trade them easily. However, this warrants a much deeper look: how do you distinguish claim rights and ownership rights? What are the differences in tokenization between different asset classes? What is impeding tokenization from adoption?

Thinking comprehensively about tokenization requires an understanding of blockchains and smart contracts, legal, finance, and economics. There has already been in-depth research on each of these components.

In this piece, I want to give a comprehensive introduction to tokenization through using real estate as a primary example. Here’s what we’ll discuss:

• What exactly is Tokenization? (Is it not just securitization?)
• What are the real benefits of tokenization? (Why do we even bother?)
• What are some of the tougher issues to think about? (How do we ask the right questions?)
• What are the challenges for tokenization? (What’s stopping adoption?)
• How will the tokenized future be? (What are some elements?)

Let’s get started!

What is Tokenization?

Isn’t Tokenization just securitization?

For structured finance professionals, tokenization might seem like securitization. In summary, securitization consists of a few steps:

1. Originator (owner of the assets) collects the assets in a pool and transfers the pool to a legal entity (usually a special purpose vehicle). Through this legal structure, assets are not exposed to counter-party risks or risk of bankruptcy of the originator bank
2. The SPV structures the assets within the pool into several tranches, according to different risk levels and characteristics usually. Securities are issued, and backed by the cash flows generated by the underlying assets.
3. After issuing the securities, the SPV sells the securities to investors, whilst transferring the proceeds to the originator afterwards.

Securitization has various flaws.

The classic securitization process is extremely costly and takes up a lot of time. The entire process might cost up to millions of dollars and takes up to a year. The securitization process requires agreements with various parties under conditions of asymmetric information, as well as a heterogeneous structure of asset data.

Furthermore, there might be a lack of full transparency in the various stages of securitization, all of which hinder auditing and rating of the underlying assets. In the sub-prime mortgage crisis, there is no transparency on the credit pool nor the audit process that lead to defaults on the bonds issued.

Clearly, tokenization =/= securitization

Tokenization — in its simplest definition — refers to converting an asset into a digital token on the blockchain system. The biggest difference between tokenization and securitization, is how programmability is introduced into the tokenized asset. This way, business logic can be introduced, reducing the need for manual settlements. Smart contracts can have functions for automatic transactions, formulas for calculating asset prices and other specific features.

What are the real benefits of Tokenization then?

Photo by @sanfrancisco, Unsplash

Numerous research pieces have talked about various benefits of tokenization, but these various benefits can be categorized into three core principles: 1) liquidity, 2) programmability and 3) immutable proof of ownership.

Key Principle 1: Liquidity

World Economic Forum predicts that over the next ten years, 10% of the world’s GDP will be stored in crypto assets, amounting to $10 trillion. This is primarily due to increased fractional ownership, and unlocking of liquidity premiums.

Assuming no legal and regulatory barriers, tokenization allows for increased fractional ownership. Most tokens can be broken into 18 decimals, as compared to fiat which can be broken down to $0.01 only. Fractional ownership lowers the barriers of entry for new investors. For instance, instead of paying $1 million for a new apartment, I can pay $50,000 for a tokenized fraction of the real estate. For investors, fractional ownership and lower barriers help them to increase portfolio diversification and construct a “truer” market portfolio.

The increase in liquidity helps unlock value for markets through liquidity premiums. When illiquid assets become more liquid, a liquidity premium of approximately ~20–30% is unlocked. One example is real estate: Even a fractional improvement in the sales price of such investments could result in trillions of dollars of new value for issuers and resellers.

Key Principle 2: Programmability built into tokens

Programmability refers to the ability to introduce certain business logic into smart contracts, allowing for automated events to occur. Tokenization can also lead to easier management of investors and their rights. Secondary transactions can be easily tracked by collaborating with third-party exchanges, allowing investors to receive distributions and exercise their other rights (e.g., voting) through the blockchain.

Programmability is especially useful in increasing the speed of settlements. In traditional finance, settlements refer to the process of documentation of the transfer of asset ownership before the ownership of assets actually changes hands. Compliance can be programmed into the tokens, if all participants have a digital identity that has gone through the relevant compliance/KYC/AML checks.

Key Principle 3: Immutable proof of ownership

Blockchains are immutable and keep a public trace of every transfer, and owner. This digital trace of transactions not only proves the history of ownership but also helps to ensure less fraud. The immutable structure makes it impossible for a token-holder to “double-sell” a token — accepting a transfer for the same token to two different sources. This helps assure investors that no one can falsify transactions after the transaction has happened.

Let’s dive deeper into tokenization.

Tokenization is the process of digitally storing the property rights to a thing of value (asset) on a blockchain or distributed ledger, so that ownership can be transferred via the blockchain’s protocol. What are the other challenges?

Issue #1: What are the requirements for tokenization to take place?

There are 3 fundamental requirements:

1. The rights to an asset can be stored digitally on a blockchain

Let’s go back to the real estate example. If I want to tokenize my house, I must be able to record my ownership of my house on a token itself. This means that to regulatory authorities, holding a token represents an ownership right or claim right on the house itself. (We will go into these rights in a bit.)

2. These rights can be legally transferred via blockchains

Whilst I can document my rights to my house in a legally-recognized way, I should be able to transfer these rights to anyone I want and that person will have legal ownership of my house, assuming my tokens are imbued with ownership rights.

3. Tokens can be easily exchanged for value, giving the assets “value”

Lastly, like any security, I must be able to exchange my real estate token for value easily — so I can subscribe value to the asset.

Issue #2: What are the other legal issues to consider?

Apart from the 3 requirements, what is more crucial to take note is the exact asset you are tokenizing: Does the token represent a claim on the asset or does the token represent actual ownership of the asset itself? Investors and token issuers must think carefully about what exactly a token represents.

The truth is: it depends on what you want to tokenize. Tokenization is flexible. Using real estate as an example again, what can be tokenized could be direct ownership in the real estate (being a partial equity owner), right to rental income, or even the right to use an asset (renting the apartment).

Hence, a token could represent ownership of the underlying real asset, an interest in a debt secured by the asset, an equity interest in a legal entity that owns that asset, or a right to the cash flow from the asset.

There are 3 basic categories of rights to understand.

The rights bestowed by tokenized securities (or security token) can be very complex to understand. However, tokenized securities can include claims to the assets (and usually the resulting cash flows), direct ownership rights, governance rights or a combination of all.

1. Claim rights: Claims to only certain specific uses (and claims) of the asset
2. Ownership rights: Equity ownership and control of the asset
3. Governance: System by which a group of people can come to unified decisions

Let’s illustrate this with real estate again, with a few examples on the token holders’ rights:

1. Claim rights, but no ownership rights: Token holders are entitled to cash flows from ongoing leases, but they have no ‘equity’ and ‘ownership’ of the underlying real estate
2. Claim rights, AND ownership rights: Token holders are the ‘owners’ of the underlying real estate with claims to the cash flows. They can make decisions directly: how much to charge for rent, investments made to maintain the real estate, hiring staff and given the proceeds from the sale of the real estate.
3. Only ownership rights: This example is rarely the case, but it means that token holders are now the ‘equity owners’ of the real estate.

What are the challenges that arise from these different rights?

It is possible that there is a separation of claim rights and ownership rights, and this creates misaligned incentives between both parties.

What if… the tokens have ownership rights for token holders? How do 1,000 token holders make decisions collectively for the best of the assets? Is there a need for delegated voting or decision making?

What if… the tokens only imbue claim rights for token holders? The token issuers (owners) can reduce profits and cash flows to the token holders, by re-investing the profits. This will be to the detriment of token holders who originally look towards the future cash flow.

The smart contract geek might ask: can’t one automate all these logic in smart contracts?

No, smart contracts cannot solve all these issues.

Contracts and smart contracts are incomplete:

1. Contracts are only enforceable when events and actions can be verified by a third party

This is the long-standing problem of “oracles” in tokenization. There are some events that can be captured in code, but near impossible for any arbiter to determine if they really happened.

For instance, I issued out real estate tokens to holders so they can receive a portion of the rental income. However, it is possible that I do not document down all the rental agreements so token holders do not know what the real amount of rental income is. If this cannot be enforced effectively, there is no rational reason for parties to abide by the smart contract.

2. It is near impossible to write a contract that contains all possible conditions and events, hence achieving “completeness”

The problem with contracts is not what is in them, it is what is not in them. It is very costly and operationally challenging to write down every condition and event. Furthermore, events and conditions change in real life — and contracts have to adapt to these real-life changes.

Given the limitations of smart contracts as inherently incomplete, certain asset types should not be tokenized.

What should not be tokenized?

1. When the blockchain cannot fully capture the change of ownership of assets

There are some assets in markets where I can sell the physical asset outside of the protocol directly, despite it being tokenized. For instance, I can tokenize real estate and transfer the token (with ownership rights) to you, but it is possible I can also legally sell the same real estate to another.

There are also other cases when I can trade tokens, but have no guarantees that I can verify the authenticity of the underlying asset. In the case of real estate, it is easier to verify, but other examples include gold bars. If it takes a lot of costs and resources to verify the authenticity, tokenization might not be a viable solution.

2. When the use of prices impede the protocol from achieving its objectives

There are some situations in which we don’t want prices to determine who gets what. Sometimes, prices do not capture external societal benefits and costs, and might not be the most equitable way to allocate resources. Examples include social goods, for instance.

3. Sometimes, we just do not want to tokenize some ‘assets’ and rights

For instance, rights to birth certificates or educational records should not be tokenized since they represent a unique right. We do not, and should not tokenize these ‘assets’.

Clearly, there are some asset classes that _should no_t be tokenized, given real-life limitations.

How do you really tokenize?

We have walked through the what and why of tokenization, now let’s talk a little about the how of tokenization.

There are a few categories of assets that have been tokenized:

• Fiat currencies

The tokenization of fiat currencies gave rise to stablecoins. Tether is the first example, creating USDT. However, there are inherent challenges with Tether. For a good, updated summary on stablecoins, I suggest this:

Stablecoins are now officially in vogue again
_With seemingly one new project unveiling multi-million-dollar funding every other week, no one will blame you for…_blog.goodaudience.com

• Gold

An example of a gold tokenization project is Digix.

Each DGX token is 1:1 gold-backed, and 1 token represent 1 gram of 99.99% gold from London Bullion Market Association-certified refiners, with gold stored in The Safehouse vault. Purchasing 1 DGX token is equivalent to purchasing actual gold itself.

• Real Estate

My primary interest lies in real estate, given the analogy between REITs and tokenized real estate. A few interesting examples are how a Manhattan real estate property was most recently tokenized, or how a portion of the St. Regis Aspen is tokenized. In the case of St. Regis Aspen, each Aspen token represents an indirect ownership interest in a common stock of the St. Regis Aspen REIT. According to Elevated Returns, the “REIT provides tax efficient structure while the blockchain provides peer-to-peer investing and cross-border transaction made simpler for investors.”

Clearly, there are many challenges associated with tokenization.

1. Lack of tokenization standards and legal infrastructure

Tokenization is not simply the creation of a token — any Solidity developer can do it. Instead, it’s about the design of the whole system, including understanding the various rights and issues we’ve talked about previously.

How do tokenization standards cater for these issues:

• Incentives (claim rights, ownership rights, governance)
• Privileges of users and system admins (who operate the token contracts)
• Life-cycle management of an asset (issuance, payouts, withdrawal)
• Security management
• Integration of KYC/AML requirements across different jurisdictions
• Integration with exchanges
• Interoperability between different public chains

In the case of cross-chain interoperability, we do see different chains with different nascent characteristics. For instance, Ethereum has scalability issues but provides for more complex Turing-complete smart contracts. How about other public blockchain networks like Stellar or IOST or Zilliqa?

How can tokenized assets (in the form of tokens) be interoperable across these different chains?

2. Digital identity that’s globally and legally-recognized

From a regulatory point of view, it is a regulatory nightmare for assets to be issued and transferred across citizens of different legal jurisdictions.

Suppose I am an EU resident looking to tokenize my real estate and the token only imbues claim rights. How do I transfer this token to U.S persons, whilst taking into account their identity, KYC/AML issues, U.S regulations, taxes and all the other issues?

How can I reasonably and easily deal with a verified, attested U.S person in a legally-compliant way for both our national jurisdictions?

3. Tokenization does not mean instant liquidity

Liquidity is the biggest challenge in the security token space and it does not happen organically. History has given us various examples of financial markets and instruments that have not yet achieved significant levels of liquidity. Helping to create liquidity through allowing institutional investors or accredited retail investors — through custodian solutions will be key. Of course, the underlying asset must be useful.

How do we introduce long-term, sustainable solutions for large institutional investors — the market makers — to create and maintain liquidity?

What does a tokenized future look like?

I’m generally bullish on a tokenized future: a fairer, more equitable world with lower barrier to entry and capital requirements for individuals or businesses.

Through capturing value in tokenized assets, we can re-create all the sophistication of the existing financial and operational world we live in, with far less operational costs and complexities. When combining tokenization with reasonably complex business logic enabled by smart contracts, we can represent complex business interactions faithfully and more efficiently.

There will be interoperability, through standardization

ERC 20 for token standards, as an example

If the ecosystem for global assets becomes interoperable, it means we can hold ownership claims to a commercial building, early-stage equity, corporate bonds, a T-bill, a single-family residence, and a decentralized network on the same platform.

Different assets can reference each other contractually and interact in an automated way. It means an increased liquidity for all (tokenized) asset classes.

ERC 725 for Identity, as another

Fabian Vogelstellar — creator of the ERC 20 standard — is leading the front for a unique decentralized identity for “humans, groups, objects and machines”. Quoting directly from the ERC 725 Github itself, “ This identity can hold keys to sign actions (transactions, documents, logins, access, etc), and claims, which are attested from third parties (issuers) and self-attested (#ERC735), as well as a proxy function to act directly on the blockchain”.

You can read more here about ERC 725 here:

ERC: Identity · Issue #725 · ethereum/EIPs
_eip: title: ERC-725 Identity author: Fabian Vogelsteller (@frozeman) discussions-to…_github.com

There are notable projects that have been working on implementing ERC 725 identity contracts. A few examples are: Origin Protocol and Rate3 Network.

Managing Identity with a UI for ERC 725
_At Origin, we’re building a platform for decentralized, peer-to-peer marketplaces. You can imagine a future Airbnb-like…_medium.comRate3 Cross-Chain Identity Protocol — Identity and Claims (ERC 725, ERC735)
_At Rate3, we initially wanted to build a blockchain-based settlement and clearance network for businesses. We…_medium.com

The future of tokenization is not here (yet), but it will be sooner than we know

We are optimistic and bullish for the future of tokenization and tokenized securities. There are many elements of the envisioned tokenized future that we observe today:

1. Governments are increasingly partnering with private companies to create infrastructural solutions

One such example is the collaboration between NASDAQ, Monetary Authority of Singapore (Singapore’s Central Bank) and Singapore Exchange (Singapore’s main stock exchange) to develop Delivery versus Payment capabilities for settlement of tokenized assets across different blockchain platforms to improve operational efficiency and reduce settlement risks.

MAS and SGX partner Anquan Deloitte and Nasdaq to harness blockchain technology
_Singapore, 24 August 2018… The Monetary Authority of Singapore (MAS) and Singapore Exchange (SGX) today announced a…_www.mas.gov.sg

2. Projects have recognized the need for compliance, and are creating solutions that target automated compliance and AML/KYC

We have touched about the need to meld real-world legal requirements into the blockchain space. There are various projects that have been doing these globally:

1. Harbor: A compliance platform and protocol to ensure tokenized securities comply with existing securities laws at issuance and on every trade, everywhere across the globe.
2. Rate3 Network: A protocol that handles asset-tokenization and identity management across both Ethereum and Stellar blockchains.
3. Polymath: A security token platform on which regulatory-compliant tokens can be built

I do notice more blockchain projects building tokenization solutions targeted at different asset classes, different ways of modeling structured finance through issuing both debt and equity tokens, for instance. More importantly, these solutions know that working directly with regulatory authorities, collaborating with central banks and other projects will help to improve the overall ecosystem.

Ensuring the legally-compliant design of the whole system is key.

3. “Paths of least resistance” will help everyone relate existing real examples to upcoming tokenization projects

Real estate have always been quoted as an example for tokenization projects. This is due to the structure of real estate investment trusts (REITs), that one could relate more easily to tokenized structures.

Tokenized real estate is not REITs, but there are various principles we can use to help us understand, relate and think better: property rights, economics for REITs for instance.

Not everything will be tokenized, but those that can be will be.

Disclosure: I work at Rate3 Network, a dual-protocol that handles asset-tokenization and identity management across both Ethereum and Stellar blockchains.

When I first read the original bitcoin whitepaper published by Satoshi Nakamoto (2008), it clarified a lot of fundamental questions I had regarding the cryptocurrency and blockchains in general. The paper, as many well-read blockchain and crypto professionals will confirm, is a fantastic starting point for anybody looking to learn more about the technology.

The goal of this post is to walk you through the whitepaper while making it as digestible as possible for anybody that is new to the field. I will aim to simplify some parts while maintaining the accuracy of the content.

Let’s stall no longer and dive right in. 🙌

PDF: Bitcoin: A peer-to-peer electronic cash system.

Before we start…

A blockchain is a ledger or database. It is distributed across and maintained by a large number of nodes (computers) in contrast to it being held by a single authority or party. The goal of the technology behind cryptocurrencies such as Bitcoin is to make it possible to reach an agreement (consensus) on the validity of the data in the database and that of data to be added to the database 🤝. Data, in this case, refers mainly to online transaction data that determines ownership of digital assets such as cryptocurrencies or tokens.

The entire distributed ledger is kept up to date and verified, and all participants in the network agree on its validity. Without immediately diving into the technical workings, blockchain protocols such as the one underlying Bitcoin, allow this agreement and validation to be achieved without the need for a third-party intermediary, such as a bank 🏦.

In the past, such a party was necessary in order to verify ownership of money (i.e., can this person spend this money). The party also made sure that an online payment was only spent once. (i.e., that particular money is not used in another transaction). The latter issue is what is referred to as the double-spend problem.

This has always been a major issue for transacting digital assets. It is possible to duplicate the code that makes up the asset and use it in multiple transactions.

The name “blockchain” comes from the way the data is stored. Data are collected in blocks 📦 which are added to a chain ⛓️ of previously validated blocks. With this as an introduction, let us get straight to it and dive into the ever famous whitepaper.

by Mike Alonzo via Unsplash

Abstract

The abstract of the whitepaper goes quite deep right of the bet and serves as a small summary of the paper. Do not worry if this goes over your head initially 🙆‍‍. We already covered most of what you need to know and will add to this in the next section.

The only takeaway here should be that the paper proposes a peer-to-peer electronic cash system. The system allows us to make online payments directly to each other. There is no need for a bank to solve the problems of ownership and double-spending. 💁 → 💵 → 🙋‍ and ❌🏦?

“A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.”

Introduction

“Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments.”

At the time of writing of the Bitcoin whitepaper, financial institutions were necessary to verify ownership and eliminate the double spend problem. This, together with the need for transactions to be reversible (financial institutions have to deal with mediation disputes), increases the costs associated with a transaction. This means that there is a minimum transaction size necessary for these financial institutions to execute on it. Their fee needs to cover the transaction costs at least otherwise it does not make any sense. If it has not been clear before: banks really enjoy making money 💸.

“… limiting the minimum practical transaction size and cutting off the possibility for small casual transactions.”

This eliminates the option for a vast amount of transaction opportunities that theoretically exist but are practically not feasible. An amazing application that is not possible due to this minimum transaction size is the micro-consumption of online content, whether these are web articles, videos, music, and so forth. Instead of having to pay a monthly subscription, which may or may not be worth it depending on the usage by the consumer, micro-transactions would allow for a user to make incredibly small automated payments as the content is being consumed.

This would radically change the way we use the internet. Paying for Medium articles per word, YouTube videos per second, Spotify music per minute, or even consuming internet bandwidth per megabyte.

Another possible application would be to realize micro-payments directly between Internet-of-Things devices. A simple example here would be a parked car paying for its parking spot by the minute. There are countless micro-consumption/transaction applications, many of which will only become more apparent in the future. This is simply not possible if we need a third-party intermediary.

“With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need.”

by Rawpixel via Unsplash

Another reason why the need for trust is not ideal when making online transactions is that in order to obtain said trust, personal information has to be collected, whether this is by the banks or by the merchants via which payments are made. This information is stored by these organizations (often on a single server), giving them control over the personal data and making the data prone to leakage or hacking 👾.

Incredible data hacks have taken place over the last decade — think of Yahoo and Equifax — and they are becoming more prominent by the day. What Bitcoin aims to accomplish is to, in some way, replicate the simplicity of an in-person transaction in an online environment.

If Andy hands Brenda a $10 note 💵, Brenda does not have to know anything about Andy (such as personal information, credit scores, net worth, etc.). The only thing she has to know is that the $10 went from being in Andy’s possession to be in her possession and that the $10 did not magically duplicate itself (💵 → 🧙‍ → 💵💵) and Andy has another (exact) replica to spend.

by Sharon McCutcheon via Unsplash

“In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.”

In order to make this possible, the person (or people, or thing) under the name Satoshi Nakamoto presents an electronic payment system that uses cryptographic proof 👨‍🏫 that allows its members to reach an agreement (consensus) without the need for a third-party intermediary.

2. Transactions

“Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key.”

In the world of Bitcoin, those that own Bitcoins have what is called a “wallet”. This functions somewhat similar to a classic wallet in that it “holds” your Bitcoin. Associated with the wallet is a public key. This is an address that can be used to send Bitcoin to, just like somebody has an email address or a bank account number.

Also, there is another (VERY important) key that is associated with a wallet that is called a private key 🔐, which sort of functions as its password. Signing with this private key is the only way somebody can prove their ownership of the wallet, and it is what enables them to send the Bitcoins in that wallet. You lose this key (and depending on the type of wallet, your seed words), you lose your BTC 🙈.

Note that the order actually goes as follows:

• When a wallet is set up, that wallet generates a random private key.
• From that private key (using an Elliptic Curve Digital Signature Algorithm) a public key is generated (note that it is not possible to convert this back to its private key; it’s a one-way algorithm).
• From that public key (something we will discuss in the Privacy section) a wallet address is generated.

Owning Bitcoins does not mean you actually have coins sitting in your wallet. A Bitcoin is not a piece of code you own or that is stored somewhere. The value of the BTC associated with a wallet (let’s call it ABC123) is based on how many transactions on the blockchain say “Address EXAMPLE890… sends x amount of BTC to address ABC123” as well as how many say “Address ABC123… sends x amount of BTC to address EXAMPLE453”.

In other words, the Bitcoin blockchain stores an incredible amount of data that specifies who sent how much to what address 📒. This data (who sends, what amount, who receives) is stored in individual transactions. The ownership of Bitcoin is calculated by looking at all the transactions coming into to an address and those that go out.

Now, if address ABC123 wants to spend the BTC that has been received from another address, it has to prove it is allowed to do so by signing the transaction with its private key 🔑 (that conditional data — you can only use it if signed with the correct private key — can be found in the previous transaction that is called upon). A new transaction is generated, the BTC is sent, and we start again. Keep in mind that this is a simplified version; some details will be added later.

Core takeaway: Bitcoins are not actual coins, they are just a combination of transactions that prove you have BTC to spend. Private keys are used to sign transactions and verify ownership.

“The problem of course it that the payee can’t verify that one of the owners did not double-spend the coin.”

“The only way to confirm the absence of a transaction is to be aware of all transactions.”

Confirming the absence of a transaction is done by broadcasting each transaction to the entire network 📡 and creating a shared history of all previous transactions (chronologically).

3. Timestamp Server

“A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash…”

The idea here is to collect the transactions that have been publicly broadcast into blocks, timestamp them (adding a time value 🕔), adding some more relevant data (we’ll get to this later) and then running it through a SHA256 hashing algorithm ⏩.

What this basically does is it converts the block and its data into a string of characters that can be used to uniquely identify that block (only that combination of data will get you that hash value). Each new block (before being added and run through a SHA256) can now refer back to the hash of the previous block in the chain, creating a chain of blocks in chronological order. This way, everybody can see which blocks (and its transactions) have taken place in the past and in what order.

This chain of blocks that are linked via their hash value is what makes up the actual blockchain (“blockchain” is often used to refer to entire protocols and systems but really it is the actual chain of blocks itself; the actual database).

4. Proof-of-Work & 5. Network

All right. Seems great! Though, how do we make sure the data that is added to the chain is actually correct? Can anybody just add blocks with transactions that do not exist? 🤔

“To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system…”

What is needed is a system that demands some work to be done before being able to add or suggest a new block to the blockchain. Just like the infamous CAPTCHA on the web, the goal is to create a barrier where it becomes harder (and infeasible) to spam the system (or in Bitcoins case, suggest false data). Bitcoin does this as follows.

I mentioned above that transactions are broadcast to the entire network. At this point, they are not yet added to the chain. Miners (those that are going to perform the “work” to add the block to the chain) are going to perform the previously mentioned hashing. They collect these transactions and put them in a block (as Merkle Root, we’ll discuss that later) together with the aforementioned timestamp, previous block hash, and some other relevant data like block height (what block # in the chain), and more.

Having collected all this data in a block, they run it through the SHA256 hashing algorithm. Again, what this basically does is it converts all that data into a string of characters that uniquely identifies that block and its data. Change a tiny thing in the block’s data and the entire hash changes (there is no known pattern for this but it is not random; change it back and you will get exactly the same hash).

Look at how the hash changes when I add the number “1” to the string of characters.

_Hashing the original title. [Xorbin SHA256 Hash Calculator](https://www.xorbin.com/tools/sha256-hash-calculator" rel="noopener" target="blank" title=")

_Adding “1” to the title. [Xorbin SHA256 Hash Calculator](https://www.xorbin.com/tools/sha256-hash-calculator" rel="noopener" target="blank" title=")

The Bitcoin blockchain does not demand just a hash; it wants a hash that starts with (at the moment of writing) seventeen 0’s 😲.

For example: 000000000000000006fb217d70740a895ce4966e2826325e31061bc433d7b186

How do miners get that hash? They need to add a number to the block’s data which is called a ‘nonce’ (they add it just like I added the “1”). Nobody knows what number is needed to find the correct hash 🤷‍‍. The only way to find it is through trial-and-error: guessing.

“… we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block’s hash the required zero bits.”

This process, guessing the right nonce, is what is referred to as ‘mining’ ⛏️. The miners with the largest CPU resources (most computational power) have the highest chance of being the first to find that correct nonce.

As long as more than 51% of the CPU power is in the hands of honest nodes, it will be impossible for a malicious miner to consistently win the mining process and add false data to the chain. The longest chain is always the chain that is taken as the truthful chain.

“… the proof of work difficulty is determined by a moving average targeting an average number of blocks per hour. If they’re generated to fast, the difficulty increases.”

This process of adding a new block to the blockchain happens every 10 minutes or so. This is kept stable by the protocol adjusting the mining difficulty (# of starting 0’s) — also called “difficulty bomb” 💣 — accordingly as computational power grows over time.

6. Incentive

Why would miners go through all that effort and pay a lot of money to obtain the computational power to mine?

Once the block is agreed upon, an extra transaction is added to the beginning of the block (often referred to as the ‘coinbase transaction’) which allocates newly created BTC to the winning miner’s wallet address, rewarding them for the work put in and providing a way to distribute coins into circulation 💰. On top of that, each transaction in the block has a small — at least that was the goal — transaction fee associated with it which also goes to the winning miner.

“Once a predetermined number of coins have entered the circulation, the incentive can transition entirely on transaction fees and be completely inflation free.”

We are going to skip over part 7 (Reclaiming Disk Space) and part 8 (Simplified Payment Verification) and will briefly discuss these sections at the end. Although they are an important part of how Bitcoin operates, for the sake of understanding the core of the paper, they are less so.

9. Combining and Splitting Value

“To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally, there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.”

Something we already touched upon a bit earlier is how transactions are made up and how address value is calculated.

The BTC value held in an address is basically the sum of all its potential input transactions (i.e., the value of all the transactions towards that address that have not been spent). When the address holder wants to spend its BTC, they cannot just take exactly that amount and send it. They have to use their input transactions as whole pieces to do so (kind of like how you need to pay with an entire dollar note and can’t cut it in pieces to pay with). So what does that mean in the practical sense?

Andy is back 👋 but now he has a wallet with 0.5BTC. This value comes from three unspent transaction outputs (UTXO) (or future input transactions; the UTXO function as a reference for the input transaction for a new transaction):
a) 0.15BTC
b) 0.27BTC
c) 0.08BTC

Andy wants to send 0.38BTC to Brenda (lucky Brenda… 🙅). When he generates this transaction, the Bitcoin protocol will take the needed inputs that together are equal to or higher than (≥) the payment to Brenda and will use those as whole pieces to generate two output transactions.

In our example, the input transactions a and b are used (0.15 + 0.27 = 0.42) to generate the payment output transaction of 0.38BTC to Brenda, as well as another output transaction to Andy’s own address which returns the change (0.42–0.38 = 0.04). Both these output transactions can function as new input transactions for future payments by the address holders.

Note: There is also a miner/transaction fee involved that is taken out of the equation. So, the change that is returned is a bit less.

Core takeaway: Output transactions require whole input transactions that together are at least equal to or more than the output value. Any excess (Inputs -(payment+miners fee)) is returned as change and can be used as a new input transaction.

10. Privacy

We already discussed the existence and usage of wallets, public keys, and private keys earlier. In the situation where a third-party stores our information (like a bank), privacy is obtained by limiting the access to that information by handling permissions and securing the servers on which it is stored.

However, as mentioned before, these provide a single point of failure and attack, making it prone to loss and hacking. So, how does the Bitcoin go about providing privacy if all transactions are openly broadcast to the entire network? 🙃

by Ryan Born via Unsplash

“The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous.”

The idea here is to keep the public key anonymous 🕵️. As long as people cannot associate a public key with a particular person, there is no way to reveal its identity.

A way of doing this that is currently used in the protocol is via the generation of wallet addresses, with a wallet being able to hold multiple addresses. Instead of showing public keys in the transaction data, wallet addresses are used. Just like public keys are created based on private keys using a one-way algorithm, the same is done to generate a wallet address from a public key (using the SHA256 followed by a RIPEMD160). What we are left with (after running it through a BASE58CHECK to make it more readable) is a wallet address that is used in the transaction data.

“As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner.”

Without diving into to much detail, multiple addresses can be generated from a single private key by implementing a counter and adding an incrementing value in order to create sub-private keys (which can be used to create public keys that in its turn can be used to generate wallet addresses). This way, a single private key can give access to a wallet that has transactions going in and out of multiple addresses (this is referred to as a deterministic wallet).

Many Bitcoin software and services handle this auto-creation of wallet addresses when executing a transaction, making it nearly impossible to reveal the identities behind a publicly broadcast transaction.

We will briefly walk through the leftover pieces of the whitepaper, and then wrap it up.

7. Reclaiming Disk Space

“Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.”

When a transaction is buried under enough blocks, meaning it has been thoroughly validated by the system, it does not necessarily need to keep storing all the transaction data in the block. This is possible without breaking the hash by including only the Merkle Root of all transactions in the block’s hash, and not the individual transaction data. For more information on Merkle Trees 🌲, check out Wikipedia.

In short, all transactions are hashed and those hashes are paired before being hashed again, and so forth until you reach the parent hash of all transactions, called the Merkle Root.

8. Simplified Payment Verification

In order to verify a payment, a user only needs to be able to link the transaction to a place in the chain by querying the longest chain of blocks and pulling the Merkle branch in which the transaction exists. If that user can do so, they can trust that the transaction has been valid given that the network has included it and further blocks have been build on it.

11. Calculations

This dives into the more mathematical background of why the network will be secure when more than half of the network consists of honest nodes.

Basically, as long as there are more honest nodes than malicious nodes, as the chain grows it becomes harder and harder for an attacker to generate an alternate chain that allows them to take back payments they have made. The more blocks that are added on top of a particular transaction, the lower the probability becomes that an attacker can catch up with an alternate chain.

That is why we often see the number 6 when talking about (block) confirmations, which basically refers to 6 blocks that are added after the transaction was included, and functions as the complete confirmation threshold.

Done

There we are! 👏 We have covered pretty much the entire original Bitcoin whitepaper. This paper has functioned as the genesis of the blockchain technologies that we see today. Getting a better grasp of its contents will definitely help you understand the current ecosystem of the industry.

I really hope this article has helped you out. If so, claps would be greatly appreciated and do let me know in the comment section below what your thoughts are on the piece. I would love to hear what you think. Any suggestions, corrections, or feedback is all greatly appreciated.

All the best,

Valentijn | @vvdhout

Why Infura?

There are a lot of pain points being faced by blockchain which may be solved by Infura and/or the InterPlanetary File System (IPFS), to some extent. These are the main challenges:

1. It’s expensive to store data on the Ethereum blockchain
2. It’s tough to configure an Ethereum geth client
3. It’s tough to scale the infrastructure

If you use Infura, access to the Ethereum network and the IPFS becomes a lot faster. It no longer takes hours to sync up the geth client which uses up a huge chunk of memory and bandwidth while the entire blockchain gets downloaded.

Here are some other advantages that come with using Infura:

• Huge amounts of data can be stored on the IPFS, and just the hash of the file can be stored on Ethereum.
• Infura provides secure, reliable, scalable, and easy to use APIs to access the Ethereum network and the IPFS. Developers do not have to worry about the infrastructure of an Ethereum node or an IPFS node. That is taken care of by Infura.
• Infura provides TLS enabled public endpoints.
• The code is portable on Ethereum’s interface using JSON RPC, Web3.
• Infura is practically a developer’s Swiss Army knife, and also saves the deployment team from the hell of scalability issues.

• And finally, Infura is trusted:

dApp Description

Our dApp will take a file as input from a user and upload it to the IPFS by invoking an Ethereum contract. The hash of the file will be stored on Ethereum.

This is the process we’ll go through:

1. Take file as an input
2. Convert file to buffer
3. Upload buffer to IPFS
4. Store hash of file returned by IPFS
5. Get user’s Metamask Ethereum address
6. User confirms transaction to Ethereum via Metamask
7. IPFS hash is written on Ethereum

dApp Architecture

Tech Stack Involved

• React — Front end library
• Solidity — The language used to build smart contracts that runs on Ethereum
• IPFS — Decentralized storage
• Infura —API access to Ethereum network and IPFS

Let’s Code!

Make sure you already have Metamask downloaded. If not, download it from here.

Also, keep your Node and NPM up to date.

Install the following dependencies:

$ npm i -g create-react-app$ npm install react-bootstrap$ npm install fs-extra$ npm install ipfs-api$ npm install web3

After you’re done, run the following command on your CLI to create a sample React project. I’ll name my project ipfs.

$ create-react-app ipfs

Deploy the Smart Contract on Ropsten Testnet

.Make sure you’re on Ropsten testnet on metamask.

To deploy the smart contract, we need ether. To get ether for Ropsten testnet, go to https://faucet.metamask.io/.

To deploy the smart contract, go to https://remix.ethereum.org.

pragma solidity ^0.4.17;

contract Contract { string ipfsHash;  function setHash(string x) public {   ipfsHash = x; } function getHash() public view returns (string x) {   return ipfsHash; }

}

Save the address of smart contract. Mine is: 0x610DD75057738B73e3F17A9D607dB16A44f962F1

Also, save the Application Binary Interface (ABI) in JSON. It can be found in the ‘compile’ tab, under ‘details’.

Mine is the following:

[ {  "constant": false,  "inputs": [   {    "name": "x",    "type": "string"   }  ],  "name": "sendHash",  "outputs": [],  "payable": false,  "stateMutability": "nonpayable",  "type": "function" }, {  "constant": true,  "inputs": [],  "name": "getHash",  "outputs": [   {    "name": "x",    "type": "string"   }  ],  "payable": false,  "stateMutability": "view",  "type": "function" }]

In the “ipfs/src” directory, create the following files: web3.js, ipfs.js, and storehash.js.

File 1 — Web3.js

import Web3 from 'web3';

const web3 = new Web3(window.web3.currentProvider);

export default web3;

File 2 — Storehash.js

import web3 from './web3';

//Your contract addressconst address = '0x610dd75057738b73e3f17a9d607db16a44f962f1';

//Your contract ABIconst abi = [ {  "constant": false,  "inputs": [   {    "name": "x",    "type": "string"   }  ],  "name": "sendHash",  "outputs": [],  "payable": false,  "stateMutability": "nonpayable",  "type": "function" }, {  "constant": true,  "inputs": [],  "name": "getHash",  "outputs": [   {    "name": "x",    "type": "string"   }  ],  "payable": false,  "stateMutability": "view",  "type": "function" }]

export default new web3.eth.Contract(abi, address);

File 3 — Ipfs.js

const IPFS = require('ipfs-api');const ipfs = new IPFS({ host: 'ipfs.infura.io', port: 5001, protocol: 'https' });

export default ipfs;

Edit — Index.js

import React from 'react';import ReactDOM from 'react-dom';import './index.css';import App from './App';import registerServiceWorker from './registerServiceWorker';import 'bootstrap/dist/css/bootstrap.min.css';

ReactDOM.render(<App />, document.getElementById('root'));registerServiceWorker();

File 4 — App.js

import React, { Component } from 'react';import web3 from './web3';import ipfs from './ipfs';import storehash from './storehash';import { Button } from 'reactstrap';

class App extends Component {

state = {      ipfsHash:null,      buffer:'',      ethAddress:'',      transactionHash:'',      txReceipt: ''    };

//Take file input from usercaptureFile =(event) => {        event.stopPropagation()        event.preventDefault()        const file = event.target.files[0]        let reader = new window.FileReader()        reader.readAsArrayBuffer(file)        reader.onloadend = () => this.convertToBuffer(reader)      };

//Convert the file to buffer to store on IPFS convertToBuffer = async(reader) => {      //file is converted to a buffer for upload to IPFS        const buffer = await Buffer.from(reader.result);      //set this buffer-using es6 syntax        this.setState({buffer});    };

//ES6 async functiononClick = async () => {try{        this.setState({blockNumber:"waiting.."});        this.setState({gasUsed:"waiting..."});

await web3.eth.getTransactionReceipt(this.state.transactionHash, (err, txReceipt)=>{          console.log(err,txReceipt);          this.setState({txReceipt});        });      }catch(error){      console.log(error);    }}

onSubmit = async (event) => {      event.preventDefault();

//bring in user's metamask account address      const accounts = await web3.eth.getAccounts();    //obtain contract address from storehash.js      const ethAddress= await storehash.options.address;      this.setState({ethAddress});    //save document to IPFS,return its hash#, and set hash# to state      await ipfs.add(this.state.buffer, (err, ipfsHash) => {        console.log(err,ipfsHash);        //setState by setting ipfsHash to ipfsHash[0].hash        this.setState({ ipfsHash:ipfsHash[0].hash });        // call Ethereum contract method "sendHash" and .send IPFS hash to etheruem contract        //return the transaction hash from the ethereum contract        storehash.methods.sendHash(this.state.ipfsHash).send({          from: accounts[0]        }, (error, transactionHash) => {          console.log(transactionHash);          this.setState({transactionHash});        });      })    };

render() {

return (        <div className="App">          <header className="App-header">            <h1>Ethereum and IPFS using Infura</h1>          </header>

<hr/><grid>          <h3> Choose file to send to IPFS </h3>          <form onSubmit={this.onSubmit}>            <input              type = "file"              onChange = {this.captureFile}            />             <Button             bsStyle="primary"             type="submit">             Send it             </Button>          </form><hr/> <Button onClick = {this.onClick}> Get Transaction Receipt </Button> <hr/>  <table bordered responsive>                <thead>                  <tr>                    <th>Tx Receipt Category</th>                    <th> </th>                    <th>Values</th>                  </tr>                </thead>

<tbody>                  <tr>                    <td>IPFS Hash stored on Ethereum</td>                    <td> : </td>                    <td>{this.state.ipfsHash}</td>                  </tr>                  <tr>                    <td>Ethereum Contract Address</td>                    <td> : </td>                    <td>{this.state.ethAddress}</td>                  </tr>                  <tr>                    <td>Tx # </td>                    <td> : </td>                    <td>{this.state.transactionHash}</td>                  </tr>                </tbody>            </table>        </grid>     </div>      );    }}export default App;

And that is all!

Access your dApp at localhost:3000. Upload a file and you will see a hash generated. To make sure your file is uploaded, access it via the IPFS gateway. Make sure you accept the Metamask requests.

Access your file at: https://gateway.ipfs.io/ipfs/your IPFS hash

Mine is at: https://gateway.ipfs.io/ipfs/QmbyizSHLirDfZhms75tdrrdiVkaxKvbcLpXzjB5k34a31

To know more about IPFS, see my other articles:

Learn by doing: a nice and easy intro to the Inter Planetary File System
_Primer on IPFS_medium.freecodecamp.orgIPFS ? and Merkle Forest?
Wh_at is IPFS?ha_ckernoon.com

Thank you for reading. If you liked this, please clap! Follow me on Twitter @Niharika3297

In the previous article, we looked at different methods to generate a private key. Whatever method you choose, you’ll end up with 32 bytes of data. Here’s the one that we got at the end of that article:

60cf347dbc59d31c1358c8e5cf5e45b822ab85b79cb32a9f3d98184779a9efc2

We’ll use this private key throughout the article to derive both a public key and the address for the Bitcoin wallet.

What we want to do is to apply a series of conversions to the private key to get a public key and then a wallet address. Most of these conversions are called hash functions. These hash functions are one-way conversions that can’t be reversed. We won’t go to the mechanics of the functions themselves — there are plenty of great articles that cover that. Instead, we will look at how using these functions in the correct order can lead you to the Bitcoin wallet address that you can use.

Elliptic Curve Cryptography

The first thing we need to do is to apply the ECDSA or Elliptic Curve Digital Signature Algorithm to our private key. An elliptic curve is a curve defined by the equation y² = x³ + ax + b with a chosen a and b. There is a whole family of such curves that are widely known and used. Bitcoin uses the secp256k1 curve. If you want to learn more about Elliptic Curve Cryptography, I’ll refer you to this article.

By applying the ECDSA to the private key, we get a 64-byte integer. This consists of two 32-byte integers that represent the X and Y of the point on the elliptic curve, concatenated together.

For our example, we got: 1e7bcc70c72770dbb72fea022e8a6d07f814d2ebe4de9ae3f7af75bf706902a7b73ff919898c836396a6b0c96812c3213b99372050853bd1678da0ead14487d7.

In Python, it would look like this:

public_key_bytes = codecs.decode(public_key, ‘hex’)
# Run SHA-256 for the public key
sha256_bpk = hashlib.sha256(public_key_bytes)
sha256_bpk_digest = sha256_bpk.digest()
# Run RIPEMD-160 for the SHA-256
ripemd160_bpk = hashlib.new(‘ripemd160’)
ripemd160_bpk.update(sha256_bpk_digest)
ripemd160_bpk_digest = ripemd160_bpk.digest()
ripemd160_bpk_hex = codecs.encode(ripemd160_bpk_digest, ‘hex’)

Note: as you can see from the code, before I used a method from the ecdsa module, I decoded the private key using codecs. This is relevant more to the Python and less to the algorithm itself, but I will explain what are we doing here to remove possible confusion.

In Python, there are at least two classes that can keep the private and public keys: “str” and “bytes”. The first is a string and the second is a byte array. Cryptographic methods in Python work with a “bytes” class, taking it as input and returning it as the result.

Now, there’s a little catch: a string, say, 4f3c does not equal the byte array 4f3c, it equals the byte array with two elements, O&lt;. And that’s what codecs.decode method does: it converts a string into a byte array. That will be the same for all cryptographic manipulations that we’ll do in this article.

Public key

Once we’re done with the ECDSA, all we need to do is to add the bytes 0x04 at the start of our public key. The result is a Bitcoin full public key, which is equal to: 041e7bcc70c72770dbb72fea022e8a6d07f814d2ebe4de9ae3f7af75bf706902a7b73ff919898c836396a6b0c96812c3213b99372050853bd1678da0ead14487d7 for us.

Compressed public key

But we can do better. As you might remember, the public key is some point (X, Y) on the curve. We know the curve, and for each X there are only two Ys that define the point which lies on that curve. So why keep Y? Instead, let’s keep X and the sign of Y. Later, we can derive Y from that if needed.

The specifics are as follows: we take X from the ECDSA public key. Now, we add the 0x02 if the last byte of Y is even, and the byte 0x03 if the last byte is odd.

In our case, the last byte is odd, so we add 0x03 to get the compressed public key: 031e7bcc70c72770dbb72fea022e8a6d07f814d2ebe4de9ae3f7af75bf706902a7. This key contains the same information, but it’s almost twice as short as the uncompressed key. Cool!

Previously, wallet software used long, full versions of public keys, but now most of it has switched to compressed keys.

Encrypting the public key

From now on, we need to make a wallet address. Whatever method of getting the public key you choose, it goes through the same procedure. Obviously, the addresses will differ. In this article, we will go with the compressed version.

What we need to do here is to apply SHA-256 to the public key, and then apply RIPEMD-160 to the result. The order is important.

SHA-256 and RIPEMD-160 are two hash functions, and again, we won’t go into the details of how they work. What matters is that now we have 160-bit integer, which will be used for further modifications. Let’s call that an encrypted public key. For our example, the encrypted public key is 453233600a96384bb8d73d400984117ac84d7e8b.

Here’s how we encrypt the public key in Python:

public_key_bytes = codecs.decode(public_key, ‘hex’)# Run SHA-256 for the public keysha256_bpk = hashlib.sha256(public_key_bytes)sha256_bpk_digest = sha256_bpk.digest()# Run RIPEMD-160 for the SHA-256ripemd160_bpk = hashlib.new(‘ripemd160’)ripemd160_bpk.update(sha256_bpk_digest)ripemd160_bpk_digest = ripemd160_bpk.digest()ripemd160_bpk_hex = codecs.encode(ripemd160_bpk_digest, ‘hex’)

Adding the network byte

The Bitcoin has two networks, main and test. The main network is the network that all people use to transfer the coins. The test network was created — you guessed it — to test new features and software.

We want to generate an address to use it on the mainnet, so we need to add 0x00 bytes to the encrypted public key. The result is 00453233600a96384bb8d73d400984117ac84d7e8b. For the testnet, that would be 0x6f bytes.

Checksum

Now we need to calculate the checksum of our mainnet key. The idea of checksum is to make sure that the data (in our case, the key) wasn’t corrupted during transmission. The wallet software should look at the checksum and mark the address as invalid if the checksum mismatches.

To calculate the checksum of the key, we need to apply SHA-256 twice and then take first 4 bytes of the result. For our example, the double SHA-256 is 512f43c48517a75e58a7ec4c554ecd1a8f9603c891b46325006abf39c5c6b995 and therefore the checksum is 512f43c4 (note that 4 bytes is 8 hex digits).

The code to calculate an address checksum is the following:

# Double SHA256 to get checksum
sha256_nbpk = hashlib.sha256(network_bitcoin_public_key_bytes)
sha256_nbpk_digest = sha256_nbpk.digest()
sha256_2_nbpk = hashlib.sha256(sha256_nbpk_digest)
sha256_2_nbpk_digest = sha256_2_nbpk.digest()
sha256_2_hex = codecs.encode(sha256_2_nbpk_digest, ‘hex’)
checksum = sha256_2_hex[:8]

Getting the address

Finally, to make an address, we just concatenate the mainnet key and the checksum. That makes it 00453233600a96384bb8d73d400984117ac84d7e8b512f43c4 for our example.

That’s it! That’s the wallet address for the private key at the start of the article.

But you may notice that something is off. You’ve probably seen a handful of Bitcoin addresses and they didn’t look like that. Well, the reason is that they are encoded with Base58. It’s a little bit odd.

Here’s the algorithm to convert a hex address to the Base58 address:

def base58(address_hex):
    alphabet = ‘123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz’
    b58_string = ‘’
    # Get the number of leading zeros
    leading_zeros = len(address_hex) — len(address_hex.lstrip(‘0’))
    # Convert hex to decimal
    address_int = int(address_hex, 16)
    # Append digits to the start of string
    while address_int > 0:
        digit = address_int % 58
        digit_char = alphabet[digit]
        b58_string = digit_char + b58_string
        address_int //= 58
    # Add ‘1’ for each 2 leading zeros
    ones = leading_zeros // 2
    for one in range(ones):
        b58_string = ‘1’ + b58_string
    return b58_string

What we get is 17JsmEygbbEUEpvt4PFtYaTeSqfb9ki1F1, a compressed Bitcoin wallet address.

Conclusion

The wallet key generation process can be split into four steps:

• creating a public key with ECDSA
• encrypting the key with SHA-256 and RIPEMD-160
• calculating the checksum with double SHA-256
• encoding the key with Base58.

Depending on the form of public key (full or compressed), we get different addresses, but both are perfectly valid.

Here’s the full algorithm for the uncompressed public key:

If you want to play with the code, I published it to the Github repository.

I am making a course on cryptocurrencies here on freeCodeCamp News. The first part is a detailed description of the blockchain.

I also post random thoughts about crypto on Twitter, so you might want to check it out.

In cryptocurrencies, a private key allows a user to gain access to their wallet. The person who holds the private key fully controls the coins in that wallet. For this reason, you should keep it secret. And if you really want to generate the key yourself, it makes sense to generate it in a secure way.

Here, I will provide an introduction to private keys and show you how you can generate your own key using various cryptographic functions. I will provide a description of the algorithm and the code in Python.

Do I need to generate a private key?

Most of the time you don’t. For example, if you use a web wallet like Coinbase or Blockchain.info, they create and manage the private key for you. It’s the same for exchanges.

Mobile and desktop wallets usually also generate a private key for you, although they might have the option to create a wallet from your own private key.

So why generate it anyway? Here are the reasons that I have:

• You want to make sure that no one knows the key
• You just want to learn more about cryptography and random number generation (RNG)

What exactly is a private key?

Formally, a private key for Bitcoin (and many other cryptocurrencies) is a series of 32 bytes. Now, there are many ways to record these bytes. It can be a string of 256 ones and zeros (32 * 8 = 256) or 100 dice rolls. It can be a binary string, Base64 string, a WIF key, mnemonic phrase, or finally, a hex string. For our purposes, we will use a 64 character long hex string.

The same private key, written in different formats.

Why exactly 32 bytes? Great question! You see, to create a public key from a private one, Bitcoin uses the ECDSA, or Elliptic Curve Digital Signature Algorithm. More specifically, it uses one particular curve called secp256k1.

Now, this curve has an order of 256 bits, takes 256 bits as input, and outputs 256-bit integers. And 256 bits is exactly 32 bytes. So, to put it another way, we need 32 bytes of data to feed to this curve algorithm.

There is an additional requirement for the private key. Because we use ECDSA, the key should be positive and should be less than the order of the curve. The order of secp256k1 is FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141, which is pretty big: almost any 32-byte number will be smaller than it.

Naive method

So, how do we generate a 32-byte integer? The first thing that comes to mind is to just use an RNG library in your language of choice. Python even provides a cute way of generating just enough bits:

import random
bits = random.getrandbits(256)
# 30848827712021293731208415302456569301499384654877289245795786476741155372082
bits_hex = hex(bits)
# 0x4433d156e8c53bf5b50af07aa95a29436f29a94e0ccc5d58df8e57bdc8583c32
private_key = bits_hex[2:]
# 4433d156e8c53bf5b50af07aa95a29436f29a94e0ccc5d58df8e57bdc8583c32

Looks good, but actually, it’s not. You see, normal RNG libraries are not intended for cryptography, as they are not very secure. They generate numbers based on a seed, and by default, the seed is the current time. That way, if you know approximately when I generated the bits above, all you need to do is brute-force a few variants.

When you generate a private key, you want to be extremely secure. Remember, if anyone learns the private key, they can easily steal all the coins from the corresponding wallet, and you have no chance of ever getting them back.

So let’s try to do it more securely.

Cryptographically strong RNG

Along with a standard RNG method, programming languages usually provide a RNG specifically designed for cryptographic operations. This method is usually much more secure, because it draws entropy straight from the operating system. The result of such RNG is much harder to reproduce. You can’t do it by knowing the time of generation or having the seed, because there is no seed. Well, at least the user doesn’t enter a seed — rather, it’s created by the program.

In Python, cryptographically strong RNG is implemented in the secrets module. Let’s modify the code above to make the private key generation secure!

import secrets
bits = secrets.randbits(256)
# 46518555179467323509970270980993648640987722172281263586388328188640792550961
bits_hex = hex(bits)
# 0x66d891b5ed7f51e5044be6a7ebe4e2eae32b960f5aa0883f7cc0ce4fd6921e31
private_key = bits_hex[2:]
# 66d891b5ed7f51e5044be6a7ebe4e2eae32b960f5aa0883f7cc0ce4fd6921e31

That is amazing. I bet you wouldn’t be able to reproduce this, even with access to my PC. But can we go deeper?

Specialized sites

There are sites that generate random numbers for you. We will consider just two here. One is random.org, a well-known general purpose random number generator. Another one is bitaddress.org, which is designed specifically for Bitcoin private key generation.

Can random.org help us generate a key? Definitely, as they have service for generating random bytes. But two problems arise here. Random.org claims to be a truly random generator, but can you trust it? Can you be sure that it is indeed random? Can you be sure that the owner doesn’t record all generation results, especially ones that look like private keys? The answer is up to you. Oh, and you can’t run it locally, which is an additional problem. This method is not 100% secure.

Now, bitaddress.org is a whole different story. It’s open source, so you can see what’s under its hood. It’s client-side, so you can download it and run it locally, even without an Internet connection.

So how does it work? It uses you — yes, you — as a source of entropy. It asks you to move your mouse or press random keys. You do it long enough to make it infeasible to reproduce the results.

The process of generation an entropy by randomly moving the mouse. The large chunk of symbols shows the pool.

Are you interested to see how bitaddress.org works? For educational purposes, we will look at its code and try to reproduce it in Python.

_Quick note: bitaddress.org gives you the private key in a compressed WIF format, which is close to the WIF format that we discussed before. For our purposes, we will make the algorithm return a hex string so that we can use it later for a public key generation._

Bitaddress: the specifics

Bitaddress creates the entropy in two forms: by mouse movement and by key pressure. We’ll talk about both, but we’ll focus on the key presses, as it’s hard to implement mouse tracking in the Python lib. We’ll expect the end user to type buttons until we have enough entropy, and then we’ll generate a key.

Bitaddress does three things. It initializes byte array, trying to get as much entropy as possible from your computer, it fills the array with the user input, and then it generates a private key.

Bitaddress uses the 256-byte array to store entropy. This array is rewritten in cycles, so when the array is filled for the first time, the pointer goes to zero, and the process of filling starts again.

The program initiates an array with 256 bytes from window.crypto. Then, it writes a timestamp to get an additional 4 bytes of entropy. Finally, it gets such data as the size of the screen, your time zone, information about browser plugins, your locale, and more. That gives it another 6 bytes.

After the initialization, the program continually waits for user input to rewrite initial bytes. When the user moves the cursor, the program writes the position of the cursor. When the user presses buttons, the program writes the char code of the button pressed.

Finally, bitaddress uses accumulated entropy to generate a private key. It needs to generate 32 bytes. For this task, bitaddress uses an RNG algorithm called ARC4. The program initializes ARC4 with the current time and collected entropy, then gets bytes one by one 32 times.

This is all an oversimplification of how the program works, but I hope that you get the idea. You can check out the algorithm in full detail on Github.

Doing it yourself

For our purposes, we’ll build a simpler version of bitaddress. First, we won’t collect data about the user’s machine and location. Second, we will input entropy only via text, as it’s quite challenging to continually receive mouse position with a Python script (check PyAutoGUI if you want to do that).

That brings us to the formal specification of our generator library. First, it will initialize a byte array with cryptographic RNG, then it will fill the timestamp, and finally it will fill the user-created string. After the seed pool is filled, the library will let the developer create a key. Actually, they will be able to create as many private keys as they want, all secured by the collected entropy.

Initializing the pool

Here we put some bytes from cryptographic RNG and a timestamp. __seed_int and __seed_byte are two helper methods that insert the entropy into our pool array. Notice that we use secrets.

def __init_pool(self):
    for i in range(self.POOL_SIZE):
        random_byte = secrets.randbits(8)
        self.__seed_byte(random_byte)
    time_int = int(time.time())
    self.__seed_int(time_int)
def __seed_int(self, n):
    self.__seed_byte(n)
    self.__seed_byte(n >> 8)
    self.__seed_byte(n >> 16)
    self.__seed_byte(n >> 24)
def __seed_byte(self, n):
    self.pool[self.pool_pointer] ^= n & 255
    self.pool_pointer += 1
    if self.pool_pointer >= self.POOL_SIZE:
        self.pool_pointer = 0

Seeding with input

Here we first put a timestamp and then the input string, character by character.

def seed_input(self, str_input):
    time_int = int(time.time())
    self.__seed_int(time_int)
    for char in str_input:
        char_code = ord(char)
        self.__seed_byte(char_code)

Generating the private key

This part might look hard, but it’s actually very simple.

First, we need to generate 32-byte number using our pool. Unfortunately, we can’t just create our own random object and use it only for the key generation. Instead, there is a shared object that is used by any code that is running in one script.

What does that mean for us? It means that at each moment, anywhere in the code, one simple random.seed(0) can destroy all our collected entropy. We don’t want that. Thankfully, Python provides getstate and setstate methods. So, to save our entropy each time we generate a key, we remember the state we stopped at and set it next time we want to make a key.

Second, we just make sure that our key is in range (1, CURVE_ORDER). This is a requirement for all ECDSA private keys. The CURVE_ORDER is the order of the secp256k1 curve, which is FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141.

Finally, for convenience, we convert to hex, and strip the ‘0x’ part.

def generate_key(self):
    big_int = self.__generate_big_int()
    big_int = big_int % (self.CURVE_ORDER — 1) # key < curve order
    big_int = big_int + 1 # key > 0
    key = hex(big_int)[2:]
    return key
def __generate_big_int(self):
    if self.prng_state is None:
    seed = int.from_bytes(self.pool, byteorder=’big’, signed=False)
    random.seed(seed)
    self.prng_state = random.getstate()
    random.setstate(self.prng_state)
    big_int = random.getrandbits(self.KEY_BYTES * 8)
    self.prng_state = random.getstate()
    return big_int

In action

Let’s try to use the library. Actually, it’s really simple: you can generate a private key in three lines of code!

kg = KeyGenerator()
kg.seed_input(‘Truly random string. I rolled a dice and got 4.’)
kg.generate_key()
# 60cf347dbc59d31c1358c8e5cf5e45b822ab85b79cb32a9f3d98184779a9efc2

You can see it yourself. The key is random and totally valid. Moreover, each time you run this code, you get different results.

Conclusion

As you can see, there are a lot of ways to generate private keys. They differ in simplicity and security.

Generating a private key is only a first step. The next step is extracting a public key and a wallet address that you can use to receive payments. The process of generating a wallet differs for Bitcoin and Ethereum, and I plan to write two more articles on that topic.

If you want to play with the code, I published it to this Github repository.

I am making a course on cryptocurrencies here on freeCodeCamp News. The first part is a detailed description of the blockchain.

I also post random thoughts about crypto on Twitter, so you might want to check it out.

As Bitcoin approaches mainstream adoption and recognition, its fundamental security model, characterized as mining, is being put under the spotlight and scrutinized more and more everyday.

People are increasingly concerned about and interested in the environmental impact of Bitcoin mining, the security and degree of decentralization of the underlying model, and even the potential impact of a quantum computing breakthrough on the future of Bitcoin and other cryptocurrencies.

Often times, proof-of-work is described as a “cryptographic puzzle,” but what is that puzzle, really?

In order to truly understand these questions (and any possible answers), you need to have a fundamental understanding Bitcoin mining itself and its evolution.

This article will explore all the technical components and moving parts of proof-of-work, and how they seamlessly synchronize with one another to allow Bitcoin to be the decentralized platform it is today.

Why Mining Works: Cryptographic One-Way Hashing

The Bitcoin blockchain is often described as a database that is cryptographically secure and, subsequently, immutable. The underlying technology that powers this immutability and security is cryptographic hashing.

A cryptographic hash function is a mathematical function that, simply put, takes any input and maps it to a fixed-size string.

However, there are four special properties of these functions that make them invaluable to the Bitcoin network. They are:

1. Deterministic — for any input into the cryptographic hash function, the resulting output will always be the same.
2. Fast — Computing the output of the hash function, given any input, is a relatively fast process (doesn’t need heavy computation)
3. Unique — Every input into the function should result in a completely random and unique output (in other words, no two inputs result in the same output)
4. Irreversible — Given an output of a hash function, the original input is unable to be obtained

These rules provide the foundation that enables Bitcoin mining to secure the network.

In particular, the creator of the Bitcoin protocol, Satoshi Nakomoto, chose to use the SHA-256 hash function as the basis for Bitcoin mining. This is a specific cryptographic hash function that has been mathematically proven to hold the above properties. It always outputs a 256 bit number (the most basic unit of computation), which is usually represented in the hexadecimal number system with 64 characters for human-readability.

The output of the SHA-256 function is usually referred to as the hash of its input.

A hash function’s input results in a completely unique output

Here is an example of a SHA-256 function input and output (you can try it out yourself here):

Input to SHA-256:
<Bitcoin Transaction>
Output to SHA-256:
77077b1f4c3ad44c83dc0bdb8d937e9b71c0ef07a35c2664bb7da85be738eacf

Interestingly enough, in the majority of places where hashing is used in the Bitcoin protocol, double hashing is used. This means that the output of the original SHA-256 function is then put right back into the SHA-256 function to obtain another output. Here is what that process looks like:

Input to SHA-256(first round):
<Bitcoin Transaction>
Output (first round):
77077b1f4c3ad44c83dc0bdb8d937e9b71c0ef07a35c2664bb7da85be738eacf

Input to SHA-256 (second round):
77077b1f4c3ad44c83dc0bdb8d937e9b71c0ef07a35c2664bb7da85be738eacf
Output (second round and final result):
3c6c55b0e4b607b672b50f04e028a6951aed6dc97b91e103fb0f348c3f1dfa00

Double hashing is used to safeguard against birthday attacks. A birthday attack is a scenario where an attacker is able to produce the same hash as another input by using a completely different input (called a collision). This breaks the third property of uniqueness. Without it, two completely different Bitcoin blocks may be represented by the exact same hash, allowing attackers to potentially switch out blocks.

With the SHA-256 function, the probability of this attack happening is infinitely small. If it wasn’t close to impossible, SHA-256 would be considered broken.

However, other hash functions have been “broken” in the past. In order to safeguard against this happening to SHA-256 in the future (and effectively breaking the security model of Bitcoin) it’s best to hash the hash. This halves the probability of a collision occurring, making the protocol that much more secure.

At a very high level, Bitcoin mining is a system in which all Bitcoin transactions are sent to Bitcoin miners. Miners select one megabyte worth of transactions, bundle them as an input into the SHA-256 function, and attempt to find a specific output the network accepts. The first miner to find this output and publish the block to the network receives a reward in the form of transaction fees and the creation of new Bitcoin.

Let’s take things a step further and dive into the Bitcoin blockchain itself to see what exactly it is that miners do to make the network secure.

Bitcoin Mining: A Technical Introduction

Mining was introduced as the solution to the double-spend problem. If I have 1 Bitcoin and I send it to Bob, and then try sending that same Bitcoin to Alice, the network ensures that only one transaction will be accepted. It does this through the well-known process called mining.

Before diving into the technical details, its important to understand why mining is necessary to secure the network. As fiat currency exists now, the currency we hold is created and validated by a federal reserve. Because Bitcoin operates under the rigid assumption of decentralization and consensus, no central authority can exist that validates and time-stamps the issuance of that currency and validation of any transactions that occur with that currency.

Satoshi Nakamoto proposed the only known solution at the time to solving this validation problem in a consensus-oriented system. Titled in the Bitcoin whitepaper as proof-of-work, this scheme elegantly justifies that transactions are validated by those who are willing to expend enough physical computational energy and time to do so, while simultaneously introducing an incentive to induce market competition. This competition enables the property of decentralization to emerge and thrive organically within the ecosystem.

A Look Inside a Block

A Bitcoin block consists primarily of two components:

1. Transactions, in the form of a merkle tree

Mining computers collect enough transactions to fill a block and bundle them into a merkle tree.

A merkle tree is a relatively simple concept: transactions lie at the bottom of the tree as leaves and are hashed using the SHA-256 function. The combination of two leaf transactions are hashed again using the SHA-256 function to form a parent of the leaves. This parent is continuously hashed upwards in combination with other parents of hashed transactions, until a single root is created. The hash of this root is effectively a unique representation of the transactions that are underneath it.

A visualization of how a merkle tree is built — the leaves at the very bottom of the tree are transactions

The root of the merkle tree is a combination of the hashes of every transaction in the tree.

Recall that for any any input to a hash function, the output is entirely unique. Therefore, once most nodes on the network receive a mined block, the root of the merkle tree hash acts as an unchangeable summary of all the transactions in that given block.

If a malicious actor were to try and change the contents of a transaction in a block, its hash would be changed. This change of a hash would be propagated up the transaction’s merkle tree until the hash of the root is changed. Any node can then quickly catch this malicious act by comparing the root of the changed block’s merkle tree to that of a valid block’s merkle tree.

2. The block header

The block header is a summary of the contents of the block itself. It contains the following six components:

• The version of software the Bitcoin client is running
• The timestamp of the block
• The root of its containing transactions' merkle tree
• The hash of the block before it
• A nonce
• The target

Remember that the root of the transaction merkle tree acts as an effective summary of every transaction in the block without having to look at each transaction.

The hash of the previous block before it allows the network to properly place the block in chronological order. This is where the term blockchain is derived from — each block is chained to a previous block.

The nonce and target are what make mining tick. They are the basis for solving the SHA-256 puzzle that miners need to solve.

Please note that all of this data in the block header is compressed into 80 bytes using a notation called little-endian, making the transfer of block headers between nodes a trivially efficient process. For the purposes of this explanation, we’ll ignore this compression and assume data is in its original form.

Explaining the Mining Problem

The target stored in the block header is simply a numeric value stored in bits. In traditional base 10 notation, this target ranges anywhere between 0 to somewhere in the range of 2²²⁴ (a 67+ digit number), depending on how many miners are competing to solve this problem at the same time.

Recall that the output of SHA-256 is just a number. The goal of a miner is to take the current block’s header, add a random number to it called the nonce, and calculate its hash. This numeric value of the hash must be smaller than the target value.

That’s all there is to it. But it’s much easier said than done.

Recall the first property of SHA-256: an input into a hash function will always result in the same output. Therefore, if the miner took the block header, hashed it, and realized that the hash value wasn’t less than the target, they would have to change the input somehow in order to try finding a hash below the target value.

This is where the nonce comes in.

The miner adds a number (starting from 0), called the nonce, to the block header, and hashes that value. If the hash value isn’t less than the target, the miner will increment the nonce by 1, add it again to the block header, and hash that changed value. This process is repeated continuously until a hash less than the target value is found.

A Mining Example

Here’s a rough approximation of what made up the first block header:

• The merkle root of the transaction in the Genesis block:

Merkle Root:
4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

• The first known Bitcoin version: 0.1.0
• The timestamp of the block: 2009–01–03 18:15:05
• The target (this is also the highest the target will ever be):

Target:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

• No previous block hash — this was the first block, and so this is a unique case

The final block header after adding its components together:

_The Genesis block data (this includes the nonce, but lets pretend it doesn’t), source: [bitcointalk](https://bitcointalk.org/index.php?topic=52706" rel="noopener" target="blank" title=")

Let’s take this large header and compute the double-hash:

SHA-256 of header:
7d80bd12dfdccbdde2c41c9f406edfc05afb3320f5affc4f510b05a3394e1c91

SHA-256 of the previous result (final result):
c5aa3150f61b752c8fb39525f911981e2f9982c8b9bc907c73914585ad2ef12b

Both the target and the output hash are incredibly large numbers when converted to base 10 (remember, over 67 digits long). Instead of trying to demonstrate the comparison of the two here, the following Python function handles the comparison instead:

def isBlockHashLessThanTarget(blockHash, target):
    return int(blockHash, 16) < int(target, 16)

True is returned if the hash is less than the target, false otherwise.

Here is the result with our target and block hash:

Now we take the original block hexadecimal value and add 1 to it. Here is the following result:

Notice how the very last digit is now 1, due to the addition of the nonce

We then run the same hashing algorithm and comparison on this changed data. If its not below the target, keep repeating.

Once a successful hash is found, the latest nonce used to find this solution is saved within the block.

The listed nonce on the Genesis block is 2,083,236,893.

This means Satoshi Nakomoto iterated through this process over 2 billion times before he found a hash that was acceptable.

I’ve written a small Python implementation of this Genesis block mining process that can be found on my GitHub.

subhan-nadeem/bitcoin-mining-python
bitcoin-mining-python - A Python implementation of the Bitcoin mining algorithm
github.com

See how long it would take for you to successfully mine the Genesis block!

A Caveat: extraNonce

The nonce value in a block header is stored as a 32-bit number. This means that the highest nonce anybody is able to achieve is 2³² (approximately 4 billion). After 4 billion iterations, the nonce is exhausted, and if a solution is not found, miners are once again stuck.

The solution to this is to add a field to the coinbase (the transaction contents of a block, stored as the merkle tree) called the extraNonce. The size of this extraNonce is only limited by the size of block itself, and so it can be as large as miners wish as long as the block size is within protocol limits.

If all 4 billion possible values of the nonce are exhausted, the extraNonce is added and incremented to the coinbase. A new merkle root and subsequently new block header are calculated, and the nonce is iterated over once again. This process is repeated until a sufficient hash is found.

It’s best to avoid adding the extraNonce until the nonce is exhausted, because any change to the extraNonce changes the merkle tree. This requires extra computation in order to propagate the change upwards until a new root of the merkle tree is calculated.

The Miner Reward

A miner who successfully publishes a block the fastest is rewarded brand new Bitcoin, created out of thin air. That reward currently stands at 12.5 BTC. Just how do these Bitcoins come into existence?

Each miner simply adds a new output transaction to their block that attributes 12.5 Bitcoins to themselves before beginning to mine the block. The network protocol will accept this special transaction as valid upon receiving a newly validated block. This special transaction is called a generation transaction.

Its the miner’s responsibility to add this transaction into the block before mining it. There has been at least one case where miners forgot to add the reward to the transaction before mining a block, effectively destroying 12.5 BTC!

Validating Proof-of-Work

Let’s say our miner has found a hash that is less than the target. All this miner has to do is publish the mined block with the original six components to any connected nodes.

This node receiving the block will first verify the transaction set, ensuring all transactions are valid (for example, all transactions are appropriately signed, and coins aren’t being double-spent and/or being created out of thin air).

It will then simply double-hash the block header and ensure the value is below the block’s included target value. Once the block is deemed valid, the new node will continue to propagate this block across the network until every node has an up-to-date ledger.

As you can see, newly published blocks can easily be verified by any given node. However, publishing a valid block to the network requires an incredibly large amount of computational power (thus, electricity and time). This asymmetry is what allows the network to be secured while simultaneously allowing individuals who wish to conduct economic activity on the network to do so in a relatively seamless manner.

The Block Time and Adjusting the Target

As the first miners began mining, they each monitored the block time. Each Bitcoin block has a set block time of 10 minutes. What this means is that given the current level of computing power (network hashrate) on the network, nodes will always expect newly validated blocks to be produced every 10 minutes on average.

We can reasonably expect blocks to be produced within 10 minutes because the probability of finding a block, given the network hashrate, is known.

For example, let’s take the easiest target that’s ever existed in Bitcoin: the genesis block. The probability of any single hash being less than the easiest target is 1 in 2³². That’s one in over four billion. Therefore, we can reasonably expect somebody to run 2³² iterations of the mining problem in order to find a proper hash. Nodes on the network expected four billion of these iterations to be run across all miners on the network every 10 minutes.

If, over a large sample size of blocks, blocks start appearing faster than 10 minutes, this is a pretty clear indication that nodes on the network are iterating through four billion hashes much faster than 10 minutes. This situation prompts every node to adjust the target proportionally based on the increase (or decrease) in network power to ensure blocks continue to be produced every 10 minutes.

In actuality, nodes on the network monitor the block time across 2016 blocks, which comes out to exactly two weeks. Every two weeks, the total block time is compared to the expected block time (which is 20160 minutes).

To obtain the new target, simply multiply the existing target by the ratio of the total actual block time over the last two weeks to get the expected block time. This will adjust the target proportionally to the amount of entering or exiting computing power on the network.

The formula to calculate the new target, run every 20160 minutes (two weeks) by each Bitcoin node

The block time and the ability to easily calculate the probability of finding a valid block lets nodes easily monitor and determine the total hashpower on the network and adjust the network. No matter how much computing power is added to the network or how quickly its added, on average the block time will always remain at 10 minutes.

The current total hash rate on the network is 28.27 exahash per second. That’s 28.27 x 10¹⁸ hashes run every second across all computers on the network.

In summary

We have now comprehensively covered the following:

• Why cryptographic one way hashing is vital to proof-of-work
• A breakdown of the construction of a Bitcoin block
• The actual mining process and iteration itself
• How nodes can easily validate other blocks
• How the network manages to maintain the algorithm and competitiveness by monitoring the block time and adjusting the target

You should now be able to understand and explain how proof-of-work actually functions and why it is considered to be an entirely secure algorithm that enables decentralization and consensus!

Follow me on Twitter and Medium if you’re interested in more in-depth and informative write-ups like these in the future!

If you have ever struggled through a high school math class, then you will be able to understand the principles of blockchain technology, which makes Bitcoin possible.

Have you ever tried to learn the basics of Blockchain by reading random blog posts and wikis, or watching YouTube videos?

It gets technical very quickly. You are quickly presented with concepts like:

Distributed ledger

Cryptographic hash

Digital signatures

Although you can certainly persevere through the initial confusion, you need to understand a series of new technical concepts before you understand the whole system.

Here’s why this is so hard

Bitcoin (and blockchain) are based on a distributed and decentralized paradigm. We are used to centralized, trustworthy authorities, like banks, healthcare providers, and corporations (yes, we even trust most of them).

Each one of those institutions has complicated systems in place to maintain high quality. In order to maintain these same standards for vital products without the centralized authority…we need new, complicated rules to keep decentralized systems running, too.

So, in this article, I am going to create a new high school called “Distributed High School” that operates using the principles of blockchain. We are going to create a new way to grade assignments from math class using a distributed system. Students will be able to maintain the grading system on their own, without teach involvement.

One last note: Although Bitcoin is probably the most popular application for blockchain technology in 2018, many other industries will likely begin to adopt blockchain over the next five years.

This explanation will translate most directly to Bitcoin, but it will also apply to other types of blockchains. For example, healthcare providers could use a blockchain to securely store individual medical histories.

If you are looking for a more technical explanation, this 20 minute animated YouTube video on Bitcoin is probably my favorite.

The centralized way to manage a high school

Imagine that you are a freshman in high school, and you are taking the algebra class for all 9th graders. In order to pass the class, you need to get a sufficient score on homework assignments, quizzes, and tests. There are 30 total students in your class.

All of this is managed by one centralized authority: the teacher. This one person will grade all your assignments, deliver your report cards each quarter, and make sure that nobody is cheating on tests (which would ruin the integrity of the class).

Although this is the system that we are all accustomed to, it actually has some inherent flaws.

1. It can be inefficient: when you give 30 tests to a teacher all at once, they can sometimes take a week to get them back to you — because it takes forever to grade 30 tests!
2. Sometimes it’s risky: sometimes a teacher might loses a student’s test. Or paper tests can get ruined by floods or other natural disasters. These things happen. And teachers handle so many assignments that there will probably be some errors along the way.
3. Corruptible: Have you ever been the troublemaker in the class? When the teacher sits down to grade your test, they may take one look at the name on the top of the test, and become instantly biased while grading the test. Sometimes this is hard to avoid (human nature and all that jazz).
4. Costly: All that time spent grading tests is time that could be spent doing other, more productive things. This is also probably the teacher’s least favorite part of the job. They probably became a teacher so they could help students learn, not spend all their “free” time grading tests. Instead, your parents’ taxpayer dollars are going towards an activity that could be much improved.

You can see similar issues with other centralized systems. For example, although we trust banks with our hard-earned money, the banking industry helped cause the 2008 financial crisis through risky practices that required a massive taxpayer-funded bailout.

Although we trust doctors, medical error is the third-leading cause of death in the United States, behind heart disease and cancer. Many of those errors might be caused by important medical data being inaccessible to doctors.

So, back to high school math class. You might be wondering… how the heck are we going to solve all these problems by removing the influence of the teacher, the one person with the most expertise in this system? How would we prevent it from becoming anarchy?

That is where the blockchain concept comes in. Before I get into the specific way we will use blockchain to create a new way to run Distributed High School, you should know that each blockchain has specific rules that are instituted by its creator.

In Bitcoin’s example, that would be “Satoshi Nakamoto” who wrote the original white paper and created the rules (algorithms) that allow it to operate without human intervention.

In our school example, we are going to have an exceptionally forward-thinking principal that has changed the rules.

Creating a blockchain for distributed high school

While a teacher grades tests and manages grades in private, a blockchain makes all transactions public. So, blockchain doesn’t rely on any central authority aside from the person who created it.

If you haven’t already guessed it, that means that in Distributed High School, we are going to start by having the 9th-grade students grade each other’s tests!

Let’s say it is test day, and the class period is an hour long. Students neatly stack their tests on top of the teacher’s desk when they finish.

But, instead of taking all of the tests home for grading, the teacher jumbles all of them into a big pile, and asks each student to take a random test and grade it with an answer key.

This is known as a transaction. This is the fundamental unit that makes up a blockchain. Let’s say that one student, Andy, gave another student, Alice, a grade of 84. In this case, Andy is the sender and Alice is the recipient.

In Bitcoin terms, this would not be random: you know where you are sending money!

So far, we have solved the speed and cost problems. Teachers no longer need to spend time on grading, and each student can grade one other test pretty quickly. But, there is a huge potential for fraud. This is pretty close to anarchy. There needs to be a network of responsible people that will keep all participants honest.

Here’s where the principal’s policies come in. The principal controls the one thing that everyone cares about: the grading system. At Distributed High School, the principal decides to allow seniors (12th graders) to run this blockchain system in exchange for a reward.

If a senior reviews 20 of these graded tests in 1 day, they can enter into a competition to get 10 points added to one of their own tests.

That set of 20 transactions is known as a block, and we will eventually show how all blocks work together to form a blockchain.

So why can only seniors do this? And why must it be a competition?

It must be seniors, because the principal needs participants who are going to be able to handle the workload of grading tests every day (if they want to). If the system slows down, then nobody would have their tests validated and logged, which would be a complete failure.

And it must be a competition so that the point system is not completely devalued. Imagine if every senior reviewed their 20 tests and received 10 points on their own test? Grade inflation would be rampant, similar to the way that currency inflation increases when the government prints more money. There must be a competition for a scarce number of points. I’ll share the terms of the competition later.

The principal is not forcing any senior to participate, but there is a strong incentive for them to do so.

In Bitcoin, each block has a limit of 1 megabyte (MB) of data. As of late 2017, the average transaction included about 500 bytes of data, so a block typically contained about 2000 transactions (source).

An introduction to the distributed ledger

Now we know how one test gets graded (a transaction) and the incentives in place for the seniors to maintain the system with integrity: they get more points by reviewing and validating more tests. But we are still missing the entire distributed infrastructure for how this work actually gets done.

Let’s say that 10 seniors took the principal up on his offer. They want to be part of this competition to earn more points on their own tests. Another set of 10 seniors decides to volunteer to help maintain the system, but not participate in the competition. This is simply out of support for the distributed system, and part of the spirit of the movement towards open-source grading.

Each one of those seniors is a full node in the network. They communicate in real-time about new transactions and blocks.

The 10 seniors that decided to participate in the competition are called miners. They build blocks with transactions available in the mempool, the reservoir of unconfirmed transactions.

When a student, like Andy, finishes grading a test, the student broadcasts an unvalidated transaction to the network of seniors. Each full node shares it around with everyone else, like a rumor. It becomes part of the mempool.

Every node must validate the transaction first. In other words, they determine whether it was possible or not. In this example, validation could mean confirming that the grader actually graded the test correctly by punching in all the final answers into your calculator. We will get into the other part of validation in a little bit.

After validation, each miner has the opportunity to build their own block out of 20 tests, or transactions.

But wait! On test days, 30 new transactions should be added to the network, since there are 30 students in the class. How do the miners choose the transactions to add to their block?

The answer is a transaction fee. Each sender must attach a transaction fee to their transaction to compensate the miners for their work. So, the miners usually just choose to put all the transactions with the highest fees into their blocks immediately. Since this operates on supply and demand, they can include the transactions with lower fees on days when there are fewer tests to validate.

In our school example, this transaction fee could be a point off the sender’s test to donate to the miner. It would not come off of Alice’s (the recipient’s) test. In Bitcoin, it would be a small fraction of a Bitcoin, like 0.000003 BTC. The sender pays the fee since that is the easiest way to handle the logistics.

At this point, each miner has their block of 20 validated transactions that they would like to add to the blockchain. Now, it is time for the competition to see which of the 10 miners will get their blocks accepted and be awarded the points from the principal.

One last thing. You are starting to see the amount of redundancy, or repeated work. Each proposed block will have many transactions (tests) in common. That is a security measure necessary for running a distributed system. If all the nodes are validating transactions separately, that makes it much harder to cheat the system.

The race for proof of work

Imagine that after all this work to create a block of 20 transactions, the principal then shared a 12th-grade level math problem to every miner. The person that solved the problem first was awarded all the points and had their block confirmed.

This would mean that the “rich get richer,” and it would skew the incentives for the whole system.

Every day, the top math students would have an excellent chance at winning the competition, and the rest of the seniors would have little to no chance. Soon, most miners/seniors would stop participating since they would never receive any points.

So, instead, our principal is going to set up a scavenger hunt in the school every night. Importantly, the scavenger hunt has nothing to do with a miner’s math ability. This encourages everyone to continue to mine.

The principal will hide a trophy somewhere in the school. The students must race around until they find it, and then yell so that the rest of the students throughout the school can confirm that they found it and go home. Since this principal has some magical foresight abilities, he hides the trophy in a perfect place so that it will take roughly an hour to find each night.

Does this sound arbitrary? In other words, does it feel like it came out of nowhere?

Well, it must be unrelated to the test-validation so that it can level the playing field. This is known as “proof of work” in Bitcoin. It is an algorithm that is difficult to solve, but easy for the other nodes to confirm once it is solved. Each Bitcoin miner must guess numbers until they choose the right one that solves the puzzle. In Bitcoin, a new block is confirmed every 10 minutes, on average.

Keep in mind, Bitcoin miners are really massive computers that look like this:

_[Image credit](https://medium.com/@lopp/the-future-of-bitcoin-mining-ac9c3dc39c60" rel="noopener" target="blank" title=").

The algorithm also gets gradually more difficult over time as more miners join the network. If there are more miners, that means there will be more guesses, so the challenge must get more difficult if Bitcoin wants to continue to confirm a block every 10 minutes.

This example demonstrates how Bitcoin (and our school example) force every miner to compete against the rest of the network. Once a miner solves the puzzle, they share their answer with the rest of the network, which can be quickly confirmed. After the nodes reach a consensus, or over 50% agree that the block is confirmed, it can be added to the blockchain.

This has motivated some miners to form guilds. In our school example, this means that a few of the students would agree to split the points once one of them finds the trophy. It simply increases the probability that the first one to find the trophy will be a member of their team.

In Bitcoin, the total computing power that is working on solving this “proof of work puzzle” is called the hash rate. The largest Bitcoin guilds control about 10% of the hash rate, which still gives the rest of the miners a good chance to solve the puzzle. If a guild contained 50% of the hash rate, there would be less incentive for others to continue to mine.

Once a block is confirmed, the miner receives the prize (10 points on a test) and all the transaction fees from the confirmed transactions. Transactions that were not part of the block then return to the mempool to be included in a future block.

Building a blockchain

So far, we have covered most of the steps that go into adding one more block to the blockchain. But, we have not covered the whole point of building a blockchain itself.

A blockchain has a simple three-level structure. A series of transactions make up a block. And a series of blocks make up a blockchain.

Although you can certainly divide a blockchain into pieces based on timing, usually, each individual node (senior) will maintain the full history of the blockchain, or the ledger.

In our high school example, we are looking at a 9th-grade class. So, the full history of the class could be all of the grades from all of the students in the entire class, from kindergarten until today. Since we are adding blocks at a 1-day interval, and there are approximately 180 days in the school year, that would mean that the blockchain contains about 1700 blocks.

Each block has a unique ID, which, due to a “hash function”, depends on the block ID of the previous block. That is what secures the blockchain: there is no such thing as block substitution, or rewriting history, because it will change the block ID of every subsequent block.

Since our education example uses one-day intervals, you might think, “Oh, it should be easy to create a unique ID for each block, since each date only occurs once!”

But, that would introduce a security vulnerability. If a miner was able to introduce a new block somewhere in the middle of the chain, it would not break the pattern! The deviant miner would easily be able to replicate the block ID, and none of the following blocks would change their value, since dates follow a dependable pattern that can be easily replicated.

Here is a hash generator that you can play around with. I wish there was some wonderful analogy I could give you for the block order, but unfortunately, that is the point of the hash function. It makes it very, very hard to imitate and replace blocks (impossible, as far as we know). So, I will add some random strings to show what is going on.

We are going to cover privacy in the next section, because right now, it looks like every 12th grader can see the entire grade history of each 9th grader. That is not what we want!

But, on the plus side, the distributed ledger allows each individual senior to ensure the validity of the graded tests as they circulate around the network.

This ordering system is relative, rather than absolute. The order of the blocks matters much more than the times that they were added to the chain. Timestamps, as we discussed above, are too easy to copy and imitate.

Let’s give an example of what is known as a double spend attack. Let’s say that one of your classmates takes a math test on a Monday, and knows that she did poorly. One of your classmates grades that version of the test and then broadcasts it to the nodes, per usual.

Your classmate who did poorly studies like crazy that night, and then shows up the next day to take the same test with another class. Maybe the teacher didn’t notice her there the day before — so she is able to convince the teacher that she was not present on the previous day. Remember, the teacher has no role in grading tests, so the teacher cannot quickly reference the previous day’s exams. The student is allowed to take the test again, and submits it with the rest of the class.

Here are the latest options for blocks from the blockchain, with Alice’s attempt to override her previous grade.

Oh, by the way, Alice will now need to become a miner on the network and participate in the scavenger hunt. She is now the 11th miner on this network.

The rule is that the “longest chain wins.” That means that on Day 11, the rest of the network may be working on adding a new block with the latest set of transactions. But Alice will be working on “forking” the chain, and adding a new set of transactions for day 10 with 19 transactions in common, and her new test score as a replacement for the old test score.

Forking means that she is attempting to build a new longest chain, as opposed to the chain that the rest of the network assumes is the longest.

If she can win the scavenger hunt that day, and then come back the next day and win it again, she would have the longest chain.

This is part of the value of the “proof of work” system. Since Alice is one of 11 miners on the network, she has an approximately 1% chance of solving two blocks in a row. There is a 99% chance that she will put in all that work just to get nothing. Not a great incentive.

This is also why the block IDs and previous block IDs are a better labeling scheme than a specific date. If Alice wins the race on the day that she secretly takes the test a second time, all the new tests from that day will still be eventually stored in the blockchain. They will just need to wait one more day.

Introducing public and private keys

So far, we have covered all the mechanics that will allow the students of Distributed High School to manage their own grades. We are missing just one major thing: privacy!

Right now, the grades of each individual student are exposed forever on the blockchain. If this were a currency, it would be easy to figure out how much money each person had. That is not what we want.

At the same time, the transparency is a great way to keep individual people accountable for unfair grading and other fraudulent practices.

This is why Bitcoin uses a cryptographic system with public and private keys. In high school, you are probably used to the lockers that line pretty much every hallway.

Well, in Bitcoin, there are an (essentially) unlimited number of private-public key combinations. So instead, imagine that this high school’s walls are lined with the little mailboxes that you see in an apartment building.

And they cover every wall in this whole dang school. And, since there are an unlimited total number of lockers, each student in the school can own an unlimited number of lockers. In math terms:

Unlimited/30 students = Unlimited

Have you seen Harry Potter and the Order of the Phoenix?

It’s like the scenes from the “Hall of Prophecy” — seemingly limitless.

But anyway…

For the sake of simplicity, let’s assume that each student gets 1 mailbox for each grade in school (9th-12th) during which they took tests. If a student is in 9th grade, that means they are using their 9th grade locker.

Let’s return to our transaction, where Andy grades Alice’s test.

Our full nodes, the wonderful seniors, must first evaluate whether Andy is qualified to be grading 9th grade math tests. Andy needs to prove himself.

Here’s an issue: if Andy happily announces to the network that he has graded Alice’s assignment, he risks exposing Alice. What if she got a failing grade? She doesn’t want the whole world to know that, forever!

So, he must broadcast while keeping both of them anonymous. He can randomly slip a note to one of the nodes…just like most rumors in 1980's high school movies start!

Then the full node would share this rumor with the rest of the network.

This is where our public keys come into play. When Andy slips a note about his graded test to the network, he is really saying:

• My current mailbox address is 126900trl.
• In order to prove that I was there on test day, here is the answer key that the teacher gave me to grade this specific test (digital signature).
• Also, in order to prove that I am indeed a 9th grader in algebra class, here are the final exam scores from math class each year from grades 1–8, and the answer key for each of those tests (transaction chain).
• I am going to be delivering the test to mailbox 856734pok

This is answering two key questions:

1. Is the sender the actual person that he/she claims to be?
2. Is the sender qualified to be the sender (grade the test)?

In order to answer the first question, Bitcoin uses a digital signature. The digital signature is unique to every transaction and is formed with a hash of the transaction ID and private key. In this case, that is kind of like the test key: you can only own it if you were there on the specific test day and the teacher gave it to you.

For the second question, remember that in Bitcoin there is no concept of an “account” or “account balance.” If there was, Andy could just share an ID number that proved he was qualified.

In order to prove that this particular public key (Andy’s public key) has the sufficient approval, he must share a test history that every full node can validate. That way, everyone can validate that he completed 1st-8th grade. Andy must also provide the answer key for each of those tests to prove that he was in the room at that time. This is called the transaction chain. I will not cover it here, but it is an important part of validation.

_[Image credit](https://www.cryptocompare.com/wallets/guides/how-do-digital-signatures-in-bitcoin-work/" rel="noopener" target="blank" title=").

After Andy’s transaction is validated and then included in a block that has been confirmed, he can go drop the test off in Alice’s mailbox without public knowledge.

As you noticed in the transaction above, Andy had to access tests from the last 8 years! This locker system only allows Andy to access his tests.

Andy has a set of 8 private keys. Every time he started a new year, he opened another locker and put his grades from that year in the locker.

Others can slide his latest test results into his locker, but only he can then retrieve the results.

Bitcoin software like Coinbase allows you to create many public/private key combinations within your wallet. This improves security. You never want to give away your private keys, which are the only way to access the Bitcoins that have been transferred to you. Unlike a traditional bank, there is nobody to turn to if you forget or lose a private key. The Bitcoin will be locked up.

Final Thoughts

To recap, we have:

• Tests (Transactions)
• Answer keys (Digital signatures)
• 9th graders (senders and recipients)
• 12th graders (full nodes)
• Principal (blockchain creator)
• Unlimited mailboxes (public/private keys)
• No teachers grading tests (centralized authority)
• No report cards (Accounts/account balances)

Much of this system revolves around the concept of being “trustless,” as you have probably seen by the careful checks and balances and incentive structures. In the traditional playbook for administrating banking or public education, trust in a central authority plays a huge role. In order to give that control back to individual people, there must be a huge amount of redundancy from the nodes to prevent fraud, as well careful security protocols to prevent hackers from infiltrating the system.

But, this distributed system could revolutionize the way that many industries handle their data, and could help prevent industrial accidents, medical malpractice, and financial ruin.

If you haven’t already noticed, there is a huge amount of duplicated work across all the full nodes. Between validating and confirming transactions, as well as guessing answers to the “proof of work” as quickly as possible, the system consumes plenty of energy. According to one estimate, the Bitcoin network consumes as much energy as the country of Denmark! But, this is also necessary to form a consensus and maintain the integrity of mining.

Get More Visual Explanations

Did you enjoy this tutorial? Give it a clap, leave a comment, or sign up here to get my latest technical explanations:

The internet is going crazy about this new buzzword called “Blockchain.” I am sure you have heard about it too, from your friends, investors, users or team members. As a technology, blockchain is so new and popular that people don’t have a proper idea about it and its applications.

In this article, let me help you correct the ten misconceptions about blockchain on a superficial level.

1. Cryptocurrency is the only application of blockchain

Creating a cryptocurrency seems like the most popular and viable application of blockchain today. This is also an easy way of making money by launching an ICO (Initial Coin Offerings) where investors buy your virtual coins with fiat currency or other coins like ETH, BTC, and so on.

Starting an ICO and making money quickly definitely looks tempting and is one of the reasons why it became massively popular. Take a look at the top 99 cryptocurrencies in the market right now and their current value, 99coins.

On a side note, the ease of launching an ICO opened doors to many scams like the “Vietnamese Modern Tech” scam, where a fake company raised $658M by promising to build tech internet giants in the country.

But in reality, there are multiple real-world applications of blockchain, and cryptocurrency is just one of them. Here are a few of them:

1. Healthcare: Blockchain can help us keep health records securely with proper timestamps, so they don’t get lost. The current health care systems have a massive amount of data, and they aren’t managed and connected to the internet properly.
2. Banking: Blockchain can help in cutting costs of settling transactions involving bonds or other financial instruments. It can help in sending money to countries where banking facilities aren’t a viable option.
3. Distributed Cloud Storage: Today, the photos and documents we upload to the cloud (Google Drive, iCloud, and so on.) are all centralized and, and everything is controlled by an organization. With blockchain, we can take full control of our data, encrypt and store them, and access them securely.

Tip: ? If you want to launch your own ICO in a few minutes without any coding, check out TokenLauncher, created by Sandeep and me.

2. The blockchain is the solution to all the problems under the sun!!

“If all you have is a hammer, everything looks like a nail.”

Just like the above quote, all the applications in the world needn’t involve blockchain. Blockchain comes with the concept of keeping the data or transactions decentralized. This means all your data is recorded forever in a network of computers. Data, once sent to a blockchain network, cannot be deleted or removed from all the systems. So, if you are thinking to build a decentralized network, think again!

3. Bitcoin is Blockchain

The blockchain is the technology that powers Bitcoin. Bitcoin is also one of the first applications of blockchain that went popular. Therefore, many people assume that Bitcoin is blockchain.

Bitcoin was initially created as an alternative, decentralized payment method. However, as the supply of Bitcoin is limited, the value has increased drastically in recent times. Today, Bitcoin is considered digital gold and people treat it as an asset rather than a mode of payment.

4. Smart contracts are legal documents!

No, they are not! The smart contract helps eliminate the need to pay intermediaries (Middlemen) and saves time and complexity. Think of them as self-executing code blocks that reside on the blockchain that no one can tamper with. However, smart contracts cannot be served as a legal document like Bonds, and so on.

5. Blockchains are always public

A public blockchain is open-source and accessible to all, and no one is in charge. Anyone can be part of the consensus in a public blockchain. However, all blockchains need not be public. You can make or create a private blockchain for your closed group of people.

In a private blockchain, the owner is a single entity or an enterprise and can delete/override commands on a blockchain, if needed. The private blockchain is also faster, cheaper, and requires less energy to operate.

6. Blockchains cannot be linked together

Most of us assume that blockchains cannot communicate with each other. Well, it’s not our fault. That’s how blockchain was implemented, initially.

However, it’s entirely possible to send data between blockchains. Cosmos, a company which is building the future Internet of Blockchain, is trying to bridge the gap between multiple blockchains by enabling them to exchange data easily.

7. Proof of work is the only way of achieving consensus

As a group of people/nodes run blockchain, they need a way to agree before committing a transaction in the network. In simple terms, the consensus is a dynamic way of reaching agreement in a group.

The most common form of consensus is “Proof of work,” where every miner has to solve a difficult problem. The reward is given to the first miner who solves each block problem. However, it’s extremely expensive and requires a lot of power to run. Hence, people invented other types of consensus. Read about various types of consensus protocols here.

Two popular alternatives to POW are:

• Proof of stake: a node/person can mine or validate block transactions according to how many coins they hold. Which means the more coins owned by a miner, the more mining power they have. Example: Neo
• Delegated Proof Of Stake: people in the blockchain vote for witnesses who are paid for their services. The top witnesses even earn a monthly salary. The amount of stake a person has determines the power of each vote. This means people who have more tokens will influence the network more than people who have very few tokens. Any witness who’s not doing their job is thrown out and replaced with another witness. Example: Steem, Lisk, and so on.

8. The Blockchain network can shut down if the creator is no longer interested

A public blockchain network cannot shut down easily. Since a blockchain is decentralized and no single authority controls it, it’s very difficult to shut it down unless all the participants in the network stop working. In most cases, it’s nearly to impossible to shut down a public blockchain.

9. Mentioning “Blockchain” in your pitch deck guarantees funding

Many people around the world want to jump into the hype train and make money out of it. We see this trend every year with new buzzwords. In 2016 and 2017, it was ML and AI. In 2018, it’s Blockchain. ?

If you are raising money without thinking deeper, the product is destined to die as the market stabilizes itself. So, beware! An investor wants a return! ?

10. Only geeks and nerds can use Blockchain

Even my cat can use Blockchain!

You don’t have to be a nerd to use blockchain. For example, to send or receive Bitcoin, all you need is a wallet that supports Bitcoin transactions, a public address, and a private key! Make sure to keep your private key secret. It takes a few seconds to create a new Bitcoin wallet. Get your wallet here.

(Bonus)

Blockchain === DLT (Distributed Ledger Technology)

Many believe that blockchain and DLT are the same. However, this is not true. DLT is an umbrella term used to refer to technologies that distribute information among multiple nodes. By this logic, we can say blockchain is a fully functional Distributed Ledger Technology.

Other protocols such as HashGraph, Nano, IOTA (Tangle Network) and so on are also DLTs, but they are not blockchain.

So, blockchain and DLT may be synonymous, but they aren’t the same. Rather, blockchain is a type of DLT.

Conclusion

I hope I was able to clear any misconceptions you might have had about the blockchain. If I left any out, please leave your comments below.

PS: I am not associated with any blockchain products that I have mentioned in my article.

PPS: My team and I are building a friendly community for developers called Hashnode. More than half a million developers hang out and discuss programming every month. Make sure to follow popular crypto communities to stay in the loop.

Flutter is Google’s new open-source toolkit for helping developers build iOS and Android apps with just one codebase. Flutter apps are written in the Dart programming language and compile to native code, so the performance is really, really great.

In this tutorial, I will show you how to use Flutter to build an app that shows the current price of different cryptocurrencies. I will walk you through the fundamentals of Flutter and Dart.

Before we start, install Flutter and the Flutter editor plugin if you haven’t done so already. The installation should be straight-forward, but if you bump into issues you can leave a comment on this post and I will be glad to help out.

For this tutorial, I will be using Android Studio, but you can also use IntelliJ or Visual Studio Code.

Also, some object-oriented programming (OOP) experience is required. Relax! You don’t need years of experience — if you know what classes and objects are, you should be fine.

Let’s get started

On Android Studio or IntelliJ, click on the File menu -> New -> New Flutter Project. If you don’t see the New Flutter Project option, ensure you have installed the Flutter plugin. If you are using Visual Studio Code, follow the steps here to create a new project.

When the page opens, select Flutter Application and click on the Next button.

The next page lets you configure the project. You can use a similar configuration like the image below. Just ensure that the Flutter SDK path points to the directory where you downloaded Flutter.

The last page lets you configure your company domain name, and you can set it to any domain name. After that, click on the Finish button.

The project creation should begin after clicking the finish button, which usually takes a few minutes.

When it’s done, your project should look like this.

A file called main.dart was created in the lib folder. It contains code for a demo app. Since we will be building our app from scratch, open up the main.dart file and delete/clear all the code in it.

If your project includes a test directory that contains the file widget_test.dart, delete this file before continuing. It contains tests for the code we just deleted.

Flutter apps are written in the Dart programming language. The main.dart file is a Dart source file (.dart extension). The Dart convention is to name source files using lowercase_with_underscores.

Let’s start writing some Dart code. We will begin with the programming tradition: printing “Hello World!”

To do that we will have to create something called the main function. The main function is a top-level function that every Flutter app has that serves as the entry point into your app. Think of it like the entrance to a house.

When you run your app on a device, execution will start from the main function. Let’s create a simple main function, so enter the following code into your main.dart file.

As you can see, creating the main function is easy. The second line contains the main function declaration: its return type(void) and name (main). The main function returns void meaning it returns nothing.

The third line does the printing to the console. We call the print function and pass a string argument to it. Note that in Dart, you can use single quotes (‘string’) or double quotes (“string”) when declaring a string literal.

To run the code, click on the green run (play) button at the top of Android Studio or IntelliJ. Ensure you have an actual device connected or you have an emulator running.

After the app successfully starts, you should see “Hello World!” printed on the console.

But if you check your device or emulator, you will see something disappointing.

A blank screen

Well, this was expected, as we are currently only printing to the console. There was nothing added to the app UI, and that is why it is blank.

So let’s fix this by adding some elements to the app UI. Our app will be using material design, so let’s add a package to the main.dart file to help with that.

import 'package:flutter/material.dart';

Just like any modern programming language, you can import a library/package to use in your code. Here we are importing the material.dart package. This package contains code that helps us create a material styled app.

The material.dart package has a function called runApp. The runApp takes a widget and attaches it to the screen. Well, what is a widget?

Widgets

You can think of widgets as views or UI elements. They are the things you see (and some you don’t see) when you run your app on a device. In Flutter, you will be using widgets a lot, because the main idea is that your app UI is made entirely out of widgets.

Flutter already comes with a suite of powerful widgets like text and images. The material.dart package we just imported has several material design widgets that we will be using shortly.

Let’s use the runApp method now to show “Hello World!” at the center of the device screen. Replace the content of the main function with the code below.

void main() {
  print('Hello World!');

  // Runs the MaterialApp widget
  runApp(new MaterialApp(
    // This is the widget that is displayed first when the application is started normally
    home: new Center(
      // The Text widget is wrapped in a center widget to center it on the screen
      child: new Text('Hello World!'),
    ),
  ));
}

Let me explain some ofthe new stuff in the code above

1. new: To create an object, you usually use the new keyword with a constructor for a class. (OOP)
2. new MaterialApp(): Here we are creating a new widget object called MaterialApp. The MaterialApp widget creates a number of useful things needed by a material design app.
3. home:: In Dart, we can clearly state the name of each parameter within the function/constructor call. The widget passed in as the home parameter is displayed first when the app is started normally.
4. new Center(child: new Text('Hello World!')) : We wrap the Text widget inside a Center widget so that the text gets centered on the screen. The Text widget is a child of the Center widget. Yes, widgets can be nested.

If you run the code again and open up your device, you should get a slightly better screen now.

Cool! We were able to show an ugly looking text centered on the device screen.

The next steps

Let’s take a few steps forward now. We will be getting the cryptocurrency prices from the CoinMarketCap API. The API returns a JSON array. Here is a sample response from the API:

[
    {
        "name": "Bitcoin", 
        "price_usd": "11525.7", 
        "percent_change_1h": "-0.18",
        ...
    },
    ...
]

We will be making a request to the CoinMarketCap API and decoding the JSON from the app. We will have to include a couple of new packages to the main.dart file.

import 'dart:async';
import 'dart:convert';
import 'package:http/http.dart' as http;

Here’s an overview of the new packages:

1. dart:async: Provides the Future class, which I will talk more about below.
2. dart:convert: Provides the json variable we will use to decode the JSON string response.
3. package:http/http.dart: Provides the function we will use to make HTTP GET requests.

Let’s add a new function to the main.dart file that makes a request to the CoinMarketCap API.

Future<List> getCurrencies() async {
  String apiUrl = 'https://api.coinmarketcap.com/v1/ticker/?limit=50';
  // Make a HTTP GET request to the CoinMarketCap API.
  // Await basically pauses execution until the get() function returns a Response
  http.Response response = await http.get(apiUrl);
  // Using the JSON class to decode the JSON String
  return JSON.decode(response.body);
}

Let’s walk through the new code

→ Future<List> : We are basically saying that the getCurrencies() function will return a List sometime in the future. It will make an HTTP request to the CoinMarketCap API and return a List of currencies when done.

The getCurrencies() function is asynchronous. If you have some JavaScript experience, you can think of Futures as Promises. I created the images below to help you understand Futures in Dart.

Bob calls the asynchronous function askKateForBalloons() which returns a Future<Balloons>

Bob can keep the Future<Balloons>

Bob can know when the Future completes

→ async and await :

Await expressions let you write asynchronous code almost as if it were synchronous. The http.get(url) function is asynchronous, returning a Future<Response> immediately when it’s called. We want to wait for the Response so we can decode the JSON string, but we also don’t want to use ugly callbacks.

The await expression evaluates http.get(url), and then suspends the currently running function (getCurrencies()) until the result is ready — that is, until the Future has completed.

To use await, the code must be in a function marked as asynchronous. An async function is a function whose body is marked with an async modifier. When you call an async function, it immediately returns a Future. The body of the function is scheduled for execution later.

You can read more about async and await in Dart here.

→ http.get(url) : Makes a HTTP GET request to the CoinMarketCap API. This function is asynchronous and returns a Future immediately.

1. JSON.decode(response.body) : Decodes the JSON string response.

Let’s test the getCurrencies() function we just created. We do that by making a call to it in our main function and printing the returned value to the console.

// Since we are using await within the main function, we have to make it asynchronous too
void main() async {
  // Testing the getCurrencies function
  // We wait for the currency data to arrive
  List currencies = await getCurrencies();
  // Before printing it to the Console
  print(currencies);

  runApp(new MaterialApp(
    home: new Center(
      child: new Text('Hello World!'),
    ),
  ));

If you run the code above, you should see the API response printed to the console.

Well, in the real world bad things can happen. For example, you might not be connected to the internet, so the request to the CoinMarketCap API will fail. For this tutorial, we will assume we are in Wakanda.

In a production app, you will have to handle network failure. You do that by putting the HTTP call in a [try…catch](https://www.dartlang.org/guides/libraries/futures-error-handling) block.

Building out the UI

Now that we have a list of currencies, let’s go ahead to build the UI to show that list.

When writing Flutter apps, you’ll usually create new widget classes. A widget’s main job is to implement a build function, which describes the widget in terms of other, lower-level widgets.

Let’s create a new Widget called CryptoListWidget. Add the code below to the bottom of your main.dart file.

class CryptoListWidget extends StatelessWidget {

  // This is a list of material colors. Feel free to add more colors, it won't break the code
  final List<MaterialColor> _colors = [Colors.blue, Colors.indigo, Colors.red];
  // The underscore before a variable name marks it as a private variable
  final List _currencies;

  // This is a constructor in Dart. We are assigning the value passed to the constructor
  // to the _currencies variable
  CryptoListWidget(this._currencies);

  @override
  Widget build(BuildContext context) {
    // Build describes the widget in terms of other, lower-level widgets.
    return new Text('Hello World!');
  }

}

Let’s walk through the new code above:

1. StatelessWidget : You will usually create Widgets that are subclasses of either [StatelessWidget](https://stackoverflow.com/questions/47501710/stateful-vs-stateless-widgets-in-flutter) or StatefulWidget, depending on whether your widget manages any state. We are using StatelessWidget because we have our data already and we won’t be updating it in this tutorial.
2. final List<MaterialColor> _colors : Variables in a StatelessWidget should be final (meaning they are constant or do not change). Here we are declaring a final variable that holds a list of MaterialColors. The underscore (_) before the variable name makes it private (inaccessible from other classes).
3. CryptoListWidget(this._currencies) : This is the constructor for our widget. It assigns the list of currencies we pass into the constructor to the _currencies variable.
4. build function: The build method returns a lower-level Widget (Text) that describes how it will look.

Let’s replace the Text widget in the build function above with a new widget called Scaffold. The Scaffold widget implements the basic material design visual layout structure. Replace the build function above with the one below.

@override
  Widget build(BuildContext context) {
    return new Scaffold(
      body: _buildBody(),
      backgroundColor: Colors.blue,
    );
  }

The Scaffold class provides APIs for showing drawers, floating an action button, bottom bar, snack bar, and so on. We will be adding a floating action button later.

You should get a warning that _buildBody() isn’t defined for the class CryptoListWidget. Let’s go ahead to create _buildBody() function inside of the CryptoListWidget class.

Widget _buildBody() {
    return new Container(
      // A top margin of 56.0. A left and right margin of 8.0. And a bottom margin of 0.0.
      margin: const EdgeInsets.fromLTRB(8.0, 56.0, 8.0, 0.0),
      child: new Column(
        // A column widget can have several widgets that are placed in a top down fashion
        children: <Widget>[
          _getAppTitleWidget(),
          _getListViewWidget()
        ],
      ),
    );
  }

The syntax here should be familiar. We are using two new Widgets:

1. Container widget: A [Container](https://docs.flutter.io/flutter/widgets/Container-class.html) widget is just a container :) (for other widgets).
2. Column widget: A [Column](https://docs.flutter.io/flutter/widgets/Column-class.html) widget layouts a list of child widgets in the vertical direction. It has a parameter called children that takes a list of widgets.

Let’s create the two functions we called in the _buildBody() function. The first one is _getAppTitleWidget() .

Widget _getAppTitleWidget() {
    return new Text(
      'Cryptocurrencies',
      style: new TextStyle(
          color: Colors.white,
          fontWeight: FontWeight.bold,
          fontSize: 24.0),
    );
  }

This function returns a regular Text widget with a style that makes it bold and white with a font size of 24.0.

The text is going to look like this when we run the app.

We can’t run the app yet because we haven’t created the other function called _getListViewWidget(). Let’s quickly create it using the code below.

Widget _getListViewWidget() {
    // We want the ListView to have the flexibility to expand to fill the
    // available space in the vertical axis
    return new Flexible(
        child: new ListView.builder(
            // The number of items to show
            itemCount: _currencies.length,
            // Callback that should return ListView children
            // The index parameter = 0...(itemCount-1)
            itemBuilder: (context, index) {
              // Get the currency at this position
              final Map currency = _currencies[index];

              // Get the icon color. Since x mod y, will always be less than y,
              // this will be within bounds
              final MaterialColor color = _colors[index % _colors.length];

              return _getListItemWidget(currency, color);
            }));
  }

The _getListViewWidget() returns a ListView widget that is wrapped in a Flexible widget. We use the ListView.builder to easily create the list. We pass in an itemCount which tells the builder how many currencies to show.

The itemBuilder callback will be called for each item and you have to return a new widget. In the code above we are calling a function called _getListItemWidget() that returns a Widget.

CircleAvatar _getLeadingWidget(String currencyName, MaterialColor color) {
    return new CircleAvatar(
      backgroundColor: color,
      child: new Text(currencyName[0]),
    );
  }

Before we create the _getListItemWidget() function, let’s quickly create the individual elements for the ListView item widget. We want each item in the ListView to look like this:

So, we have three main widgets:

1. A round icon widget with the currency name’s first character
2. A text widget with the currency name
3. A text widget with the price and percent change in 1 hour.

Text _getTitleWidget(String currencyName) {
    return new Text(
      currencyName,
      style: new TextStyle(fontWeight: FontWeight.bold),
    );
  }

  Text _getSubtitleWidget(String priceUsd, String percentChange1h) {
    return new Text('\$$priceUsd\n1 hour: $percentChange1h%');
  }

Let’s create the widgets. For simplicity sake, I created a function for each of them. The first function called _getLeadingWidget() returns the round icon with the text.

The widget will look like this:

The second function called _getTitleWidget returns the Text widget for the currency name.

The third function called _getSubtitleWidget() returns the Text widget for the currency current price and percent change in 1 hour.

Both of these widgets should look like this:

Let’s wrap all three widgets in something called a ListTile widget. The ListTile widget is based on the Material Design List documentation. It shows all three widgets in this style.

We will create a new function called _getListTile that returns a ListTile widget.

ListTile _getListTile(Map currency, MaterialColor color) {
    return new ListTile(
      leading: _getLeadingWidget(currency['name'], color),
      title: _getTitleWidget(currency['name']),
      subtitle: _getSubtitleWidget(
          currency['price_usd'], currency['percent_change_1h']),
      isThreeLine: true,
    );
  }

Finally, let’s create the _getListItemWidget() . It is going to return a Container widget that has a top padding of 5.0 and has a Card widget child. The card widget has the ListTile returned by _getListTile as it’s child.

Container _getListItemWidget(Map currency, MaterialColor color) {
    // Returns a container widget that has a card child and a top margin of 5.0
    return new Container(
      margin: const EdgeInsets.only(top: 5.0),
      child: new Card(
        child: _getListTile(currency, color),
      ),
    );
  }

The widget will look like this.

We have successfully completed our CryptoListWidget. But we have to update the main function to show the newly created widget instead of the Text widget.

void main() async {
  // Bad practice alert :). You should ideally show the UI, and probably a progress view,
  // then when the requests completes, update the UI to show the data.
  List currencies = await getCurrencies();
  print(currencies);

  runApp(new MaterialApp(
    home: new CryptoListWidget(currencies),
  ));
}

That’s it. You can hit the run button again. If everything works well and you are connected to the internet, you should a screen that looks like this.

Really cool right?

The app you see will be slightly different from the screenshot above:

1. It does not have a floating action button at the bottom right.
2. The text color of the percent change in 1 hour is black.

I decided not to include them in the tutorial. But you can check the project Github repository to see how I was able to achieve it.

The completed app can be downloaded here.

Thanks for reading and hope you enjoy Flutter as much as I do. Feel free to leave a comment below if you have any issues, suggestions, etc.

What would technology be without a computer doing periodic work?

Whether it’s your phone constantly checking your inbox for you, or getting timely alerts for weather or flight delays.

What about a bitcoin vs Canadian dollar price service, in just 56 seconds? No IFTTT, no Zapier, but no programming languages either — and no frameworks, no server or docker configuration, no Raspberry Pi, no AWS and no tests!

To make the example as universal as possible, we will only use 2 command lines:

• one to GET the bitcoin price from an API
• and another to POST it to another service.

Of course you can make this more useful by posting the price to Twitter, Twilio, Telegram, Slack and so on. But here we will simply post it to putsreq.com so we can inspect the POST request.

Then we will use GitLab-CI to schedule it to run everyday.

Level : All levels

Requirements : Any web browser

Let’s get you started :

1. Create a free account at gitlab.com (20 seconds)

2. Create a new Project : Click on the New Project button to create a new repo, and in the name field type periodic-job or any other name. (9 seconds)

Then save it by clicking on Create Project (1 second).

3. Create a .gitlab-ci.yml file in this new project: Click on New File, copy and paste the following snippet into the .gitlab-ci.yml file, then click save (5 seconds)

test:

 script:

 - btc=$(curl https://min-api.cryptocompare.com/data/price?fsym=BTC\&tsyms=CAD)

- curl -i -X POST https://putsreq.com/wkDdMQWhaOyalisaIe49 — data ‘price=CA$ ‘“${btc//[0-9\.]/}”

These are basically two simple commands. Here we can go further and add

if [ $btc -ge 15000 -a $btc -lt 7000 ]; then

conditions, or even run a full bash script file, but let’s keep it simple.

Click on the Commit changes button, and this will trigger it to build and run.

4. Schedule it to run everyday: click on the CI/CD icon to expand the menu, and select Schedules to set up a name and a timer for your periodic job to trigger. (11 seconds)

click on New schedule button

Type in a name for the new schedule daily-bitcoin-price-job, select to run it daily then click Save

Your scheduled job has been saved

5. Congrats! You’re done. Go to to this link in putsreq.com to see it in action. (10 seconds)

This job will run everyday as long as your free 2000/month build minutes do not run out.

We haven’t even scratched the surface of what we can do with GitLab-CI — just think of all the possibilities of using it to create webhooks or connecting it to IFTTT and Zapier, which in turn would connect it to hundreds of services.

In the next article we will go through what we have just done, and how we can take it up a notch and create a webhook and use it to post to social media.

You can find the sample code here, and you can read the build logs here.

If you’re not already a cryptocurrency investor, you’ve probably at least heard a thing or two about blockchain, Bitcoin, or both.

Let’s be clear: these are indeed technologies to be taken seriously, even as they’re written off by traditionalists like Warren Buffet and Jamie Dimon (who perhaps, not coincidentally, have massive investments in traditional financial institutions).

To recap, Bitcoin (BTC) is the first decentralized cryptocurrency (created in 2009) and currently the largest of more than 1,000 known cryptocurrencies. It has a market cap of about $140B USD as of the beginning of February, 2018. That represents more than a third of the nearly $400B total market cap of all cryptocurrencies tracked by CoinMarketCap.

Blockchain, on the other hand, is the technology that Bitcoin and many (but not all) of the other newer cryptocurrencies vying for a piece of the crypto-craze are built on.

Blockchain works by recording peer-to-peer transactions onto “blocks” which are subsequently written permanently onto an open and distributed ledger (the blockchain) through a consensus-based mining process. The blockchain ledger, by its open nature, is verifiable by anyone, and is resistant to modification because it’s distributed and encrypted.

_How blockchain transactions are processed (credit: http://blockchain.open.ac.uk/)" rel="noopener" target="blank" title=")

Importantly, blockchain’s design eliminates the need for “trusted” middlemen such as banks, offering a number of significant advantages over our current trust-based systems. For example, transactions on a blockchain can happen much quicker (as they are processed within minutes, automatically), more reliably, and more efficiently than traditional transactions using fiat currency like US dollars.

One important benefit from the increased efficiency is significantly reduced transaction costs. As an example, McKinsey and Company estimates that revenue from cross-border payments (transaction fees) worldwide will total $2.2 trillion USD by 2021, illustrating just how expensive it is to move money across borders (never mind the typical 3–5 day settlement times).

That’s a lot of potential cost savings to be had if the companies that provide these payment services adopt blockchain-based systems.

Cross-border payments are just one of the more obvious use cases for blockchain technology. Beyond cross-border payments and even peer-to-peer (P2P) payments, there are even more interesting use cases for blockchain, which we’ll discuss later in this story.

Why Blockchain is here to stay (and Bitcoin might not be)

In an automobile analogy (credit: Jason Schenker), you might think of Bitcoin as the first car to use an internal combustion engine and blockchain as the internal combustion engine technology itself.

While Bitcoin is the first and currently largest cryptocurrency to use blockchain technology and has excellent people behind it, many new blockchain projects are emerging that are also intriguing from a technology perspective. And yes, even Kodak (the film company) entered the blockchain fray in 2018.

Who could be next? Tech giants like Microsoft and Oracle are now incorporating blockchain into their product and service portfolios, though neither has stated any intention of creating its own cryptocurrency just yet.

Therefore, given the rapid influx of innovation and talent flowing into the global cryptocurrency community, it’s anybody’s guess whether Bitcoin will remain on top five, 10, or 20+ years from now.

It does need to be stated, however, that Bitcoin maintains a strong advantage in network effect. Bitcoin currently plays a sort of “safe haven” role as the largest and most traded cryptocurrency (thus providing the most liquidity), with less volatility (price fluctuations) than most other cryptocurrencies.

So, Bitcoin has a significant leg up on its competition right now. But things could change rapidly depending on how other cryptocurrency projects evolve.

While Bitcoin’s future prospects are anyone’s guess, blockchain, on the other hand, is almost certain to gain mainstream relevance in the future. A foundational approach to building decentralized systems, blockchain offers significant gains for just about every business across just about every industry.

The only significant question mark is just how long it will take for this promising technology to be widely implemented.

The early days saw limited differentiation

The early wave of cryptocurrencies inspired by Bitcoin’s emergence in 2009 provided limited product differentiation beyond the original peer-to-peer (P2P) payments focus.

Litecoin (LTC), founded in 2011 and currently #6 in global market cap, is essentially Bitcoin with more frequent block creation to allow faster transactions, for example. According to Litecoin founder Charlie Lee, Litecoin is intended to be “the silver to Bitcoin’s gold.”

Litecoin also positions itself on its website as complementary to Bitcoin. This suggests that there is room in the future of P2P payments for a coin whose transactions settle in just 2.5 minutes, compared to Bitcoin’s process which takes 10 minutes.

Litecoin founder Charlie Lee’s twitter profile exemplifies the complementary relationship between Bitcoin and Litecoin.

In 2012, Ripple (whose native cryptocurrency is XRP), another project that catapulted in popularity last year (and is currently #3 in market cap among cryptocurrencies), also began to offer its own take on decentralized payments.

Unlike Bitcoin and Litecoin, Ripple’s payments systems verify transactions by consensus from a much smaller number of trusted gateways, instead of its predecessors’ blockchain-based approach that requires vast amounts of computing power and electricity (to mine).

Ripple’s approach has several benefits over Bitcoin (at the cost of less decentralization): much faster transaction speeds (just seconds) and potentially lower transaction costs. Ripple has had success over the last year launching partnerships to facilitate “frictionless” cross-border payments using its payments systems.

Although both Litecoin and Ripple brought innovation to the crypto space, at the end of the day, they (and a few others) have generally been content to focus on P2P payments use cases.

Ethereum Broadens the Horizon

In late 2013, the crypto paradigm changed forever when Vitalik Buterin introduced the world to Ethereum (whose token is ETH). The emergence of Ethereum in subsequent years, particularly in 2017 when its market cap grew to nearly $100B (2nd only to Bitcoin), has validated the value of projects that unlock new use cases beyond P2P payments.

Here’s why.

Unlike Bitcoin and Litecoin, Ethereum was not designed primarily for payments. Instead, Ethereum was built to facilitate blockchain-based custom “smart contracts” and applications. Central to the Ethereum platform are mechanisms for scripting custom smart contracts that can be recorded onto the Ethereum blockchain.

This means that Ether (the token used on the Ethereum platform) can be used for all kinds of smart contracts, including but not limited to smart property rentals (think “rental economy” with AirBnB, ridesharing, etc.), financial transactions, commodity pricing, online gambling, video games, content licensing, virtual gifting, and even the creation and management of new cryptocurrency projects and initial coin offerings (ICOs).

Smart contracts on a platform like Ethereum can run the gamut from complex business arrangements to simple consumer transactions.

Ethereum lets you build “unstoppable applications,” according to the Ethereum Foundation website.

The future of differentiated dapps

Ethereum’s meteoric rise in 2017, among other developments, has facilitated a recent surge of new decentralized apps (dapps) that use blockchain technology.

Some of the most prominent dapps are themselves new cryptocurrency projects, many of which are ERC20 tokens — built on the Ethereum network, but adding customizations to either the technology or application focus.

Here are just a few of the top coin or token projects competing for attention in the exploding cryptocurrency market, in order of market share according to CoinMarketCap, as of February 7th, 2018.

1. Bitcoin
2. Ethereum
3. Ripple
4. Bitcoin Cash
5. Cardano
6. Litecoin
7. Stellar
8. NEO
9. EOS
10. NEM

What’s interesting to note is the degree to which each project on the list attempts to distinguish itself from its peers. For example, a quick look at publicly available resources for each project suggests the following primary focuses for each of the currencies on the list above:

1. Bitcoin — secure P2P payments
2. Ethereum — flexible smart contracts platform
3. Ripple — global payments with trusted gateways
4. Bitcoin Cash — P2P cash
5. Cardano — smart contracts that can be regulated for compliance
6. Litecoin — fast, efficient P2P payments
7. Stellar — global payments
8. NEO — smart contracts, pays a “dividend”
9. EOS — decentralized operating system (OS)
10. NEM — smart assets

It would appear that nobody on this list is doing the exact same thing.

Could there be room in the global economy for several or more of these projects to coexist in the future? (If so, can we stop thinking about the cryptocurrency market as an ultra-risky, winner-takes-all contest?)

And, when you consider the thousands of dapps being built that don’t even qualify as a cryptocurrency, you start to see the makings of a whole universe of distinct opportunities for enterprising entrepreneurs.

How can dapps improve real business performance?

For businesses that aren’t looking to enter the much-hyped ICO or cryptocurrency markets, there are still many reasons to build dapps.

Here are just some practical benefits that building on a blockchain can offer businesses of all sizes:

• Ability to settle transactions and close deals automatically anytime, not just during business hours (even weekends).
• Improved security (in terms of immutability) of data and applications stored on the blockchain.
• Increased business (more customers and transaction volume) due to improved operational performance (faster and more reliable transactions)
• Reduced overhead costs (such as personnel and facilities) for accounting and contracting (contract lawyers and contract management staff), and fraud prevention (for ecommerce companies, for example).
• Significantly lower average transaction costs, due to both the reduced overhead and variable costs associated with blockchain-based verification and processing.

Decentralized apps are surprisingly accessible

Next, consider that many of these leading projects (Ethereum, for example) are ecosystems or platforms, intended to attract the support of business partners and applications that will each put down their own roots on one or more of these platforms.

Much like app marketplaces like the Google Play Store, Salesforce AppExchange, or WordPress Plugin Directory who must minimize barriers for app developers that want to launch on their platforms, these blockchain platforms also need to make it easy for app developers and businesses to create and support dapps on their platforms.

It’s precisely this opportunity — to build dapps on existing dapp platforms (like Ethereum) — that is attracting companies of all sizes to the virtues of decentralization.

“Blockchain technology is interesting to many of the businesses we talk to because it can unlock tremendous operational improvements in their existing business,” explains Harry Lee, CEO of CitrusBits, a Los Angeles and San Francisco-based mobile app agency that offers blockchain development services. “For these businesses, building a ‘dapp’ isn’t just about capitalizing on investor interest in anything associated with blockchain. They’re actually out to realize the substantial ROI building decentralized apps on a blockchain can provide.”

“The bottom line is this: you don’t need to have crypto geniuses or blockchain inventors on your staff in order to tap into blockchain’s potential. With the right experts or app agency supporting you, you can now begin building your own specialized decentralized apps on an existing dapp platform — essentially piggybacking on the openness and innovation of blockchain pioneers throughout the world.”