In part I of this two-part series, we explored how transactions are sealed cryptographically making it impossible for anyone, except the owner, to claim them. We briefly talked about how those transactions are submitted through the wire and broadcasted to the full network. We also touched on how those transactions are picked up by the receiver and used in further transactions hence creating an ordering where outputs of previous transactions are consumed as inputs to a new transaction.
After a transaction is created, it needs to be written down somewhere, so that it can be referenced later. This demands a storage model where all transactions can be recorded (also known as the ledger). Why do we need previous transactions? Because in order to verify that a particular transaction was correct and not fraudulent, you have to trace it down from the very beginning (starting from Nakamoto’s account). I recommend that you pause here and think for a second why that is required? And is there a more efficient way to handle this?
This is clearly a tedious process! With millions of transactions happening every minute, you can’t be spending all your computing resources trying to figure out how the transactions are structured. There is a simple, elegant way to handle this. Store bunch of transactions in blocks and chain the blocks together. And instead of stamping individual transactions as accepted, you stamp the whole block. This way when checking whether a certain transaction was indeed correct and not fraudulent, you just fetch the previously referenced transaction along with its block and verify against that.
That summarizes the storage model in Bitcoin. But what about communication? There are various actors in blockchain — each having their own set of roles. Some are adding blocks to the blockchain. Some are simply passing on the blocks to each other — ensuring all blocks are accounted for. Some are creating/transmitting the actual transactions. Some are just verifying those transactions. Some are simply monitoring the activities that are happening on the blockchain. But how does all of this take place in a self-sustaining manner without possibility of an external influence.
Before we delve further into theories, I would like to introduce some key actors in the system. Later we will further elaborate on their purpose. These actors (more concretely: nodes) may overlap in some form, but are conceptually separate entities.
Wallet
A wallet (also known as simple payment verification node) has two responsibilities:1. It needs to scan the blockchain to see which transactions belong to him2. It needs to create the transactions which are broadcasted to the network (and eventually mined).
Seed
At all moments, each node is connected to several other arbitrary nodes; forming lattice-like structure of peer-to-peer nodes. However, in order to discover other nodes, a node must first connect to the “seed” nodes — which introduces it other nodes.
Miner
The miner puts the block in the blockchain. They pool all the unconfirmed transactions; sorting them by mining fee (highest first) and adding it onto the blockchain. This newly mined block is then broadcasted to the rest of the network. In a nutshell, a miner’s job is to convert transactions into blocks.
Relayer
A relayer just monitors activity. They can tell health of the network; participate in message passing; or query the blockchain for other statistics.
In the previous post, we left the discussion on the note that given a system of cryptographically signed transactions, it is still possible to abuse the system. How do you ensure that the transactions added onto the blockchain have not been tampered with? What if a mischievous actor starts bombarding the system with false/incorrect transactions/messages. What if someone sends x BTC to A and x BTC to B nearly simultaneously (double-spending)? Which one is to be considered valid? What if miners accept two different transactions? How do nodes coordinate amongst themselves agree on network changes? To sum it up in one question: how is the system regulated?
These are the hard problems in a cryptographically, secured network that is trust-less — in the sense that no party can jeopardize the ecosystem. All nodes must accord with the network rules and in case there are disagreements, a group of nodes can take a snapshot of the current blockchain; apply their own statutes; and branch-off forever. This famously happened in mid-2017 during the Bitcoin cash fork¹.
A key concept in the proposed solution of Bitcoin is to form a well-defined ordering of blocks. If you have ordered blocks, which is unanimously agreed on by all peers, then it would be impossible for the same transaction to appear more than once in the blockchain. A trivial approach could be to simply add indices to the blocks (1,2,3 …). A slightly better way would be to add timestamps instead of numbers, as timestamps also give additional information about block creation time and each block can then reference the previous timestamp (assuming that each timestamp is unique). There is still a glaring problem in our system. Can you see what that might be?
Anyone can create a block at any time and can spam the network with dozens of blocks². This would choke the network and Bitcoin would be entirely unusable. The solution put forth in Bitcoin white-paper is as follows: when adding a block onto the blockchain, the miner is asked to crack a cryptographic puzzle and add the resulting hash onto the block. The puzzle is designed in such a way that it is easy to verify if it was solved correctly, but harder to solve without knowing the solution beforehand. Additionally, the Bitcoin network can also tweak the puzzle periodically. For example, beginning of 2019, the difficulty of mining was roughly 1800% higher than it was 2 years ago³. This is done to counteract the rising hash power of the mining machines and maintain a balance in the system⁴. Of course, all this work would have been pointless if a miner had no incentive to mine the transactions. This is why all transactions take a fee — which goes to the miner. Prior to year 2140, miners will also collect some BTC as an extra incentive to keep mining. This hash produced as the outcome of this extra work is also used for ordering; instead of relying on timestamps. We still use timestamps on blocks, however, as they provide us with valuable information.
So far we have a timestamped, spam-protected, chained-together blocks composed of transactions that seem quite sturdy. Let test it further. Is it possible for a miner to act maliciously? For instance, can he introduce a transaction in a block which was never requested by anyone? What about two different blocks containing a set of same transactions that were produced by two different miners nearly simultaneously?
These are two separate concerns — but worth exploring. To address the first issue, we need to introduce how Bitcoin blockchain skillfully plays with hashes. A hash is a fixed-size data that is used for assuring the integrity of some input. First, we compute hashes of all transactions in a block. After that we use a technique called Merkle-root construction to compute a root hash⁵. This hash can be thought of: as a hash of all hashes. In simple terms, the root hash guarantees the integrity of all transactions in a block. It would be impossible for the miner or a relayer to introduce a transaction that was not part of the original block as that would break the hash of the overall block. Great, what about multiple blocks being produced at the same time?
This is a bit more complicated as the Bitcoin paper does not provide a concrete answer here. Instead it is left on game of chance. Unfortunately, someone has to lose this battle. Let’s paint a picture. Imagine miner X in China and miner Y in United States that both include transaction T in their block. X produces block B1 and the resulting blockchain is […A → B1], while for Y the blockchain looks like […A → B2]. Both blocks are broadcasted and relayed further until eventually 74% of the nodes are aware of a blockchain […A → B1], while 18% know the blockchain as […A → B2]. Both blockchains seem valid albeit contradicting each other. Now, a miner Y in Germany, who sees blockchain as […A → B1], produces another block C and broadcasts it. His reach is 94% of the nodes. All miners that were previously dealing with the blockchain […A → B2] and now saw this new blockchain […A → B1 → C] will decide to drop the previous chain and replace it with the latest version. If they don’t do that, and instead keep mining with the older chain, they would risk losing their mined block to the majority. At the end of the day, the most popular version of the blockchain is considered the standard. This is why, in general, it is recommended to wait up till 6 blocks before accepting a transaction as the state of blockchain might change. As a miner, you want to have access to as many nodes as possible, otherwise there is a risk that all your efforts might go to waste. On the other hand, unification of mining power poses a risk to decentralization of the Bitcoin network. If a group of miners gain 51% of the hash power, they can effectively spin-off a blockchain of their liking. This is an actual threat to the Bitcoin blockchain and currently there is no safeguards in place to ensure that this does not happen in future. The argument against it that it is highly unlikely and is in the detriment of all participates⁶.
Spam-protection (proof-of-work) combined with blockchain branching and eventual consolidation means that we should wait sometime after a transaction is broadcasted before we can say with enough confidence that it has been persisted in the blockchain network. Typically, it takes 10 minutes to mine a new block. If we wait 6 blocks, our transaction would have buried deep enough in the ledger that we can say with high degree of confidence that the transaction has gone through. But nobody likes waiting one hour for his/her coffee. And that is the bottleneck of Bitcoin. The technology can not scale for everyday usage, but leads the way for Internet money. Bear in mind, Bitcoin, itself, was a culmination of various attempts to create virtual currency. So, in my opinion, it would be incorrect to state that the technology has peaked. There are lots of improvement proposals. And the next version of cryptocurrency might deal with issues that the current system suffers from (such as volatility and transaction speed) while leveraging the concepts that Bitcoin (et al) brought forth.
Footnotes
[1] History of Bitcoin cash fork[2] Hashcash to limit spam attack[3] Bitcoin difficult chart[4] Proof of work[5] Merkle tree construction[6] 51% attack
This was a quick primer on Bitcoin. If you want to learn more about it, check out the book by Andreas Antonopoulos: Mastering Bitcoin. It covers various aspects of Bitcoin extensively. Some topics worth exploring are advanced scripting; hierarchical deterministic wallets; mining pool; and so forth.
Cryptocurrency still has a long way to go before it truly becomes Internet money. The foundation has been laid, but a lot of challenges lay ahead. Follow me on twitter to get latest updates.