A Beginner's Look at Blockchains

There has been more excitement about Bitcoin recently and, as a result, the topic has come up more often in the media. Aside from the rising price of Bitcoin itself, people seem to be mostly excited about its use in avoiding the decline in purchasing power brought on by the Fed pumping money into the economy (honest question: why not just call that inflation? Is it something to do with the Consumer Price Index not indexing relevant items or weighting them correctly?).

I come at this topic as an outsider and novice, my only previous contact being a half-read book about blockchains on a train to Oslo in 2017 and the documentary Banking on Bitcoin. There has been a persistent feeling that I didn’t quite get it, despite reading various explanations that have been provided.

As always, going back to the original paper introducing Bitcoin made things clearer, even if it raised further questions. The main thing it cleared up is what “proof of work” actually means. A scarce commodity like Bitcoin requires it to be backed by something of limited supply, in this case CPU (or more likely, ASIC) time. What is the actual problem these CPUs are solving? The paper suggests the problem of finding a nonce, essentially a dummy variable, that, when hashed along with a valuable payload (in this case, the record of transactions and the hash of the previous block) results in another hash that has an arbitrary number of leading zeros. When used with a modern random hash function such as SHA256 or SHAKE256, the only apparent way to solve this problem is by brute force.

The block in blockchain is a set of transactions, i.e., transfers of value between parties, that is to be hashed in this way. As already alluded to, each block contains a reference to its parent (or parents, if greater amounts of value need to be transferred) making a blockchain.

Length of chain is synonymous with legitimacy— the longest chain is the truth— due to an interesting aspect of chaining proofs of work together. Since each block in the chain contains a reference to all past transactions (or in practice, hashes from a Merkle tree of those transactions), a change anywhere along the chain requires every descendant block to be re-hashed (i.e. to do a new proof of work, since the value to be hashed has changed slightly). So if a crypto-thief wanted to modify a previous transaction in their favour, they would have to redo the proof of work of the altered block and all its descendants. This is tractable of course, otherwise, how was the legitimate chain hashed? The barrier to the thief is that while they are catching up to the current block, all the honest nodes in the network are ahead hashing new blocks. All that anybody has to do to be reassured they have the legitimate history of transactions is take the longest chain on offer from any node in the network, and to be sure, check that the hashes are correct and meet the leading zeros requirement.

The aspiring crytpo-thief would have to think hard about whether it would be more profitable to be honest and work on hashing the newest block rather than trying to rewrite the history of transactions. The system rewards the first node that solves the proof of work for a new block by allowing them to self-award a new bitcoin (also in the new block). The number of bitcoins in circulation is finite and capped at 21 million. Once all the bitcoins have been allocated, estimated to happen some time in the 22nd century, the hashing work can be funded by a transaction fee. In other words, value out will be slightly less than the value in for transactions in the block. N.B. I use lowercase “bitcoin” for the object and uppercase “Bitcoin” for the concept.

That’s the explanation that makes sense to me, unless I made a mistake along the way which is quite possible. To solidify my understanding, I wrote my own simple blockchain in Python using the sha256 library and the requirement of 5 (yes, 5!) leading zeros as proof of work, which takes 2-5 seconds on my machine. A notebook of the code is at the bottom of this post (disclaimer: this code is for educational purposes only). The valuable data that I wanted to secure in the blockchain are the titles to Beatles songs here, in practice it would be the amount of money paid in by party A and the amount of money taken out by party B. (My understanding is that these should match until all the bitcoin are mined.) To make the picture fuller would require creating a set of nodes, each working on the latest block, transmitting and receiving the updated blockchains from other nodes, and verifying them, but I did not get round to that here.

The questions I had after reading the paper were:

  • How is a fraudulent node prevented from catching up when the rate of new transactions is low? The rate parameter of new blocks (which they call \(\lambda\)) needs to be large enough otherwise fraudulent blockchains will be as long as honest blockchains. This appears to limit the applicability of blockchain to problems with a high enough rate of new events. I have heard of people thinking of applying blockchain to land registries so I wonder how they make that work.

  • Is there a way to make the work in the proof of work useful? Hashing numbers to have an arbitrary number of leading zeros does not have any inherent value to society. At the same time, there are many other computational problems which do have value and which are easy to verify. However, the reason why it is not so simple to merely require “proof of useful work” is that the output (e.g. hash) must depend on the parent hash and the payload. If not, then it is impossible to verify that the parent and payload are correct.

  • Is the existence of a nonce to solve any particular problem in a finite time always guaranteed? At the very least, there must exist at least one hash with the required leading zeros in the image of the hash function with the payload and parent held constant. A truly random hash would have a 1/K probability of generating a 0 in any given position, where K is the size of vocabulary in each position. But is there any property of the hash functions used in practice that ensures that we can always find a nonce for any block?

Update [December 23rd, 2020]:

I have since read the book “The Bitcoin Standard: The Decentralized Alternative to Central Banking” by Saifedean Ammous and this helped clarify some of the questions I had above.

When the new block rate \(\lambda\) is low, the difficulty of the proof of work is reduced (i.e. number of leading zeros reduced). The target rate is on the order of 1 block for every 10 minutes. Likewise, the difficulty is increased if the creation of new blocks is significantly faster than once every 10 minutes. The latter case has been true historically more than the former as increasing amounts of computational power are thrown into Bitcoin.

The next question I had was whether the proof of work could solve something of intrinsic value to society. In answer to this: a nuance that I had not noticed before is that part of the incentive for a node to act honestly comes from the risk of wasted computation that is likely to happen if it were to act dishonestly. In other words, a dishonest node has to dedicate a significant amount of computational resources towards altering blocks falsely and failure to succeed, the most likely outcome by far, means that these resources were wasted. However, if the dishonest node is able to accomplish an ancillary task in the process then this consolation prize reduces the risk-reward matrix for being dishonest. The other part that I had not appreciated fully is that society already spends vast amounts of money to secure trust, sometimes in vain. Blockchain is one of the most reliable inventions for converting computation into trust and, in that sense, we are getting a bargain.

In summary, the book reinforced for me the game theoretic aspects of the blockchain’s security. While I agree with the overall message, one aspect that the author seems to have missed is that it is possible to rapidly liquidate any Bitcoin holdings into USD and, therefore, it is not true to say that a dishonest node is is disincentivized by any potential devaluation of Bitcoin that results from their attack.