Software bugs

Back in September of last year, a bug was found in the code of Bitcoin Core versions 0.14 to 0.16.2 which could have allowed for increasing the total supply of bitcoins above 21 million. Had the bug been discovered by a malicious actor, they may have been able to use it to attack the network. Jimmy Song has provided a great analysis of this incident, and he suggests that although the likely ramifications of exploiting this bug would have created problems for the network, it was unlikely to have been fatal.

Nonetheless, the episode made vivid one more type of threat afflicting bitcoin: malfunctioning code, or software bugs. Whether through an innocent mistake in the coding, or through the malevolent design of an attacker, it is not inconceivable that there could be problems with the Bitcoin code that could cause it to malfunction.

The threat of bugs and malfunction is far more serious for Bitcoin than for most other computer programs, because Bitcoin's value proposition depends on its immutability, reliability, and complete predictability. If it is evolving to fulfill the role of digital gold, then the most important characteristic Bitcoin needs to copy from gold is its constant reliability and predictable supply. A bug that hinders the operation of the software or allows some users to create more coins will severely compromise the network and the likelihood that it would continue to succeed in that digital gold role.

Rather than focus on the technical details of this bug and how it was fixed (which Jimmy's article discusses), I would like to focus on how Bitcoin's open source development counters this threat, and how individual users could help reduce the likelihood that it could affect them.

Linus Torvalds, the original creator of the Linux operating system, famously said that "with enough eyeballs, all bugs are rendered shallow"; and that is a great explanation of the prime value proposition of open source software. While open source software usually relies on the efforts of volunteers that are not paid to be fully focused professionally on the software, its collaborative nature can attract many people to review the code and improve it, which helps prevent critical bugs from emerging. This has proven a surprisingly successful and robust model. Whereas proprietary software development resorts to employing a few full-time highly focused individuals, open source development allows anyone to contribute and gives all users of the software the choice to adopt anyone's contributions. The process of constant innovation variation and user selection creates a strong evolutionary pressure that drives the code's improvement.

Open source development is also a wonderful example of Friedrich Hayek's concept of Spontaneous Order, or order that emerges not through any preconceived individual design, but through human action. Vernon Smith builds on Hayek's work to differentiate between two types of rationality in human affairs: constructivist rationality, and emergent rationality. Constructivist rationality refers to conscious human design to bring something into being; it is similar to designing a car, a house, or any technical object that requires top-down design. The triumph of enlightenment thinking and industrial revolution, while being enormously beneficial to humanity, has nonetheless created a bias in the mind of the educated to view everything as the result of constructivist rational design. But the majority of market and societal institutions were never top-down designed by one designer, they emerged over many years through the actions and interactions of individuals. Hayek argues that the majority of the human institutions that shape our lives, from language, to customs, to economic institutions, ethics, and manners, are all emergent products of human action, and not the conscious effort of human design.

This simple but powerful concept is pivotal in understanding how human society functions; it is also something that victims of state education have the most trouble comprehending, as statist education relies on convincing students that everything needs to be rationally planned and controlled. It is also essential in understanding how Bitcoin has continued to evolve after Satoshi left the project with nobody in charge of it. In the 8 years or so since he has disappeared, the bitcoin software has improved significantly, and yet no single individual can possibly be viewed as responsible for these changes. While each individual change to the software can be viewed as a product of rational design by one or a few programmers, the choice of which changes get adopted by users, how the changes build on one another, and the general direction of open source development are a complex and emergent result of the interaction of variations and individual choices.

This is one of the most infuriating aspects of Bitcoin to statists and people who have no familiarity with Austrian concepts of spontaneous and emergent order. Lawyers, Keynesians, and all manners of people in thrall of their powerful government are constantly seeking out the person in charge of Bitcoin, and try their best to demand someone be held legally responsible for it, attempting to corporatized Bitcoin's structure and have clear chains of command and responsibility. These people simply cannot understand the concept of voluntary collaboration, and that a user who downloads open source software does so at their own discretion, not at the responsibility of the person who volunteered their time to building it.

Bitcoin's lack of central control, and the absence of a constructivist rational approach to its programming, is far from a disadvantage; conversely, it is the most effective way for it to remain predictably neutral. This lack of central control also offers a huge edge for dealing with software bugs, because a wide variety of eyeballs from all over the world examine the code and try to find mistakes within it. This is the process that keeps all manner of open source software running, as mentioned by Linus, and in the case of Bitcoin the process is put on the powerful steroids of economic incentive of thousands of people who have a vested interest in Bitcoin succeeding. In other words, what protects Bitcoin from software bugs, ultimately, is the economic incentive for its users to remove and deal with bugs as quickly as they emerge. And the recent bug is a good example of that. While it might have been theoretically possible for a well-funded attacker to exploit the bug, realistically it was highly unlikely due to the economic incentive for all Bitcoin users to detect these bugs before they can be exploited. Attacking Bitcoin offers very little economic reward, and so is unlikely to attract the same number of motivated eyeballs. An attack on Bitcoin is destined to be a top-down design with a few focused highly skilled individuals trying to execute it. Bitcoin's defense consists of many thousands of users and coders constantly vigilant and defending against anything bad happening.

As Jimmy concludes:

Bugs will always exist, but the important thing is to have a robust process for dealing with them. Open source software development has shown itself to be more reliable in the long run. Bitcoin adds to it strong economic incentives for many economic parties from developers to businesses to invest heavily in this process as well.

It is impossible to conclusively prove the absence of bugs in a piece of software, because one can only ever dismiss the bugs they can imagine, while the potential bugs are always larger than a single analyst's brain. It is nonetheless possible to have strong economic incentives for managing and dealing with these bugs. Beyond that, Bitcoin's extremely conservative and meticulous design itself ensures there is another layer of safety for dealing with any critical software failures: the ability to roll back the chain and return to the historical state before the bug had struck. This would likely mean that any critical bug will be temporary rather than permanent. If one were to compare this to aircraft maintenance, it would be akin to having a function that allows you to return a crashing flight to its pre-crash state and perform maintenance on it, inconveniencing the passengers rather than leading to their death.

The second point to take from this incident is about the speed at which Bitcoin software upgrades happen. For a project whose main value proposition is immutability, a case could be made that the current speed of upgrades and iterations in Bitcoin development is a little too fast; users might benefit from being slower with their upgrading, letting newer versions of software get tested slowly and gradually on progressively larger sections of the network nodes before they are widely adopted and accepted as stable.

There is currently no pressing need to upgrade Bitcoin or improve its capabilities. For what it does, it faces no serious competition from any digital currency. Its only competition are central banks and global
gold shipments. It is far cheaper than both for what it does, and its current capacity for final settlement is unmatched.

Even by Bitcoin's proven existing capabilities of only half a million transactions per day, which it demonstrated it could safely carry out in December 2017, and even with transaction fees that are 10 times higher than the maximum they reached last December (i.e. even with a $500 transaction fee), it is still a huge bargain for what it does; it could find significant demand either as a direct network for international payments, or as a settlement layer for a large network of Bitcoin full nodes that carry out the function of banks (either digitally or in physical locations).

There is no scaling crisis for these significant use cases, there is no impending technical threat that is likely to doom Bitcoin, and as such there are no compelling reasons why Bitcoin should change drastically from what it is currently. This is why, for users, it probably makes sense to be lagging adopters on minor updates, and to select for software versions with less frequent upgrades.

For bitcoin to succeed, it needs another, say, twenty years of functioning exactly as reliably as it has (and not necessarily at any larger scale) in order for it to be implanted in the mind of most adults as a simple and reliable boring piece of open source software that anyone can use in predictable ways. It will take a generation that has come to hear of the idea of a form of money that is not controlled by governments. It will, sadly, take the death of the most bit-ter elder nocoiners, who amassed their wealth and credibility in the constructivist rational monetary policy era and who are wholly unwilling (and in many cases, incapable) to understand the certainty of hard digital money.

When people talk about the slow rate of bitcoin adoption, the limitation is never in software capabilities or scaling capacity. The market has shown consistent capacity for scaling solutions, both on chain and off-chain. Demand for block space is an extremely competitive market, and geniuses are constantly innovating ways of utilizing it more efficiently. Even if Bitcoin successfully serves as a base layer for settlement, and secondary layer solutions develop on top of it, it would still be an enormous improvement over the current monetary system because it would be far more decentralized and harder to capture by government. There is no pressing need to risk Bitcoin's progress toward fulfilling that use case in order to upgrade its technical capabilities. Provided Bitcoin continues operating successfully, the delay in bitcoin adoption is purely a matter of time needing to do its inevitable thing and pass.

It's the same reason any technology takes time to spread. Most users will never become technically competent enough to understand all the nuances of its functioning. But time is needed. People need to see the technology operating successfully, safely, reliably, and consistently for a significant period of time. Most people eventually got on airplanes not because they studied jet aviation, but because they had seen and heard of airplanes operating reliably for years before they got into them. Similarly, people will start to trust a digital form of storage not due to an extensive study of bitcoin and cryptography, but rather after seeing it work reliably for years for others.

The critical thing, then, is not scaling, privacy, or user-friendliness, the critical thing is Bitcoin's survival. The major milestone for Bitcoin is its ability to continue as one chain of undisputed transactions among its holders. This would mean that Bitcoin's governance and security system has succeeded at all times in achieving consensus among its participants on the validity of the ledger of transactions.