Defensive Consensus: Getting to a Multi-Implementation Bitcoin Network
The word Bitcoin means a lot of things. It’s a protocol, a peer-to-peer network, a currency, and depending on who you ask, one or more open source projects.
Bitcoin is written in C++
Bitcoin Core is the C++ implementation of the Bitcoin protocol released by Bitcoin’s architect, Satoshi Nakamoto. The software is maintained and improved by over 400 contributors. The project has well-established planning (Bitcoin Improvement Proposals), development, and change-acceptance workflows, and all releases maintain backwards compatibility.
Today, the Bitcoin network is almost exclusively maintained by mining pools, exchanges, and full node operators running some version of this C++ implementation.
Alternative Implementations Considered Harmful
For those new to the Bitcoin space, this monoculture is often confusing and concerning. Why aren’t alternative Bitcoin implementations being used?
Without a central authority, there is no arbitration for “partially valid” transactions on the Bitcoin network, and there is no recourse for accidents. Instead, the network must rely on perfect consensus among all nodes.
This means consensus is critical. Any divergence might cost expensive downtime for businesses, and in the worst case, could cause some network participants to accept fraudulent transactions as valid. Satoshi echoed this sentiment:
“I don’t believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network.” — Satoshi Nakamoto, Bitcointalk (2010)
This prescient view from Satoshi has been validated both in testing and in practice.
Which Came First: the Software or the Protocol?
“This is a design where the majority version wins if there’s any disagreement, and that can be pretty ugly for the minority version […]” — Satoshi Nakamoto, Bitcointalk (2010)
In its early days, Coinbase used a Ruby implementation of Bitcoin for some part of its internal blockchain validation. In 2013, Coinbase had a number of outages, followed by days of withdrawal delays, when a difference between the Ruby and C++ implementations caused Coinbase and other Ruby users to be forked away from the rest of the Bitcoin network: while most of the network continued to mine blocks and advance the blockchain, Ruby implementations didn’t recognize the proper chain as valid.
The fork may have allowed malicious actors to steal from Coinbase and other Ruby users by tricking them into believing they had received payments on the Ruby chain.
This story has played out repeatedly, invariably coming back to bite users of alternative implementations. Often, these inconsistencies are not problems with the alternative implementation, but previously-unrecognized quirks in Bitcoin Core.
To be safe, alternative implementations must maintain bug-for-bug compatibility, that is, they must implement the exact same bugs which are present in Bitcoin Core. Examples include Bitcoin’s non-standard Merkle tree and an off-by-one error in OP_CHECKMULTISIG.
However, some developers argue that these oddities in the Bitcoin protocol are not really “bugs” in the traditional sense, since Bitcoin Core has historically been the only protocol specification for Bitcoin. In proper newspeak, these protocol-standardized bugs are really “undiscovered features”, since they’re already “properly implemented” for all clients.
Even for alternative implementations which successfully implement these known quirks in Bitcoin Core, there still exists a risk of yet-undiscovered quirks, which, to an alternative implementation, is a zero-day vulnerability.
For these reasons and more, many of Bitcoin’s most seasoned developers constantly warn about the dangers of alternative implementations. Peter Todd, one of Bitcoin’s most prolific contributors and experts, has described this issue in detail.
With an understanding of the causes of Bitcoin’s monoculture, let’s take a look at its effects.
Effects of Bitcoin’s Software Monoculture
Bitcoin’s monoculture weighs heavily on the ecosystem in a number of areas.
Discourages New Bitcoin Developers
There’s a serious shortage of developers who are able and willing to work on Bitcoin Core. Besides being written in C++ (a notoriously unforgiving programming language), Bitcoin Core is not known for its code quality. This has the general effect of discouraging new developers from becoming familiar with Bitcoin or contributing to the implementation.
“While Bitcoin Core is battle-tested and the go-to standard, the codebase is difficult to work with, even for an experienced software engineer. As a result, only a handful of developers contribute actively to Bitcoin Core — and a only few dozen individuals fully understand it and all of its unique quirks.”–Purse, Introducing Bcoin
Adds Software Integration Overhead
The safest method of integrating Bitcoin into an existing project is to use Bitcoin Core. At the very least, this requires new infrastructure for projects which may not already be using C++ libraries or external daemons. At best, this slows down development of new services. At worst, it encourages new ventures to cut corners and use alternative implementations, exposing them to risks they might not fully recognize (see above).
Raises the Stakes of Making Changes
Because any change to Bitcoin Core can introduce critical vulnerabilities, even changes which would be appreciated by most open source projects (like simple refactoring or minor feature additions) tend to be discouraged. It certainly doesn’t help that all changes must be written in a language with manual memory management.
Christopher Jeffrey, primary author of the Bcoin JavaScript implementation cites a rejected pull request he made to Bitcoin Core as a key motivation for his work on Bcoin. (video)
Politicizes Software Development
Open source projects tend to have a development nexus, and Bitcoin is no exception. There are large network effects around the ecosystem for Bitcoin Core. The project has the bitcoin slug on GitHub, a largely overlapping set of contributors with the bitcoin.org project (where its binaries are released), official support of the bitcoin subreddit, well-named IRC channels on Freenode, large Linux Foundation mailing lists, and a number of other assets which lend it serious network effects.
Since Bitcoin’s consensus algorithm makes it a winner-takes-all system, competing with Bitcoin Core is significantly more difficult than in most open source projects. To the extent that these incentives discourage independent competition, individuals tend to pursue change via more political methods, lobbying for “change from within” rather than disruptive innovation (“Voice” rather than “Exit”).
Politics poisons discourse, turns away less-confrontational individuals, and inhibits non-incremental innovation. The larger the political entity, the worse the effects. (The largest current example, of course, is the state headquartered in Washington, D.C.)
Exposes the Bitcoin Network to Additional Risk
Most importantly of all, Bitcoin’s software monoculture is an existential risk to the network and the entities that rely on it.
While Bitcoin Core has had years of battle testing, there always exists the possibility that previously-undiscovered vulnerabilities will be found. A brief glance at the list of previous vulnerabilities provides plenty of examples with real-world consequences.
In trying to protect the network from this additional risk, the development community has also made some unfortunate trade offs:
- Bitcoin Script, the scripting language which is used in Bitcoin to define and satisfy various transaction authentication requirements, has been whittled down in several ways. A number of opcodes have been completely disabled “just in case” their implementation in Bitcoin Core contained bugs.
- Standard Transactions were defined to make undiscovered bugs slightly harder to exploit, at the cost of preventing the use of new and innovative transaction types.
Given these consequences, it’s quite clear that the Bitcoin ecosystem would benefit greatly from increased diversity of protocol implementations.
How to Build a Reliable Space Ship
Bitcoin isn’t the first software system with strict reliability requirements. One of the most commonly referenced examples in the field of reliability engineering is NASA’s Space Shuttle.
Developing reliable software for aeronautics is notoriously difficult. In flight, there is no true fail-safe mode. There is no safe “default” to fall back to in the event of a software bug. If the software fails, and pilots or other systems cannot compensate, the failure will end in disaster.
Two Versions
To reduce risk, NASA hired two different teams to work on two separate systems. The Primary Avionics Software System (PASS) was developed by IBM in Houston, TX, while the Backup Flight System (BFS) was developed by Rockwell in Downey, CA. The backup system was only designed to handle a few critical functions (most importantly, landing), and was able to instantly take over in a failure scenario.
Software reliability engineering has continued to advance since 1973. While the Space Shuttle’s backup system required manual activation by the crew, modern systems can step in without human intervention.
Modern Redundancy
In the Airbus A320, three separate pairs of computers provide different but redundant functionality. Each pair is composed of two different boards (one i386 CPU, one m86k CPU) running independently developed software. One computer calculates, the other verifies. If a fault is detected, the pair withdraws itself from the cluster, and the role is taken over by the other two computer systems, mechanical systems, and/or the pilots.
Fault Tolerance in Bitcoin
Of course, lessons from aviation are only partially applicable to Bitcoin.
In one sense, aviation software’s lack of a fail-safe mode makes its development more difficult than Bitcoin development. Arguably, Bitcoin does have a fail-safe mode: all transactions can be halted. Though still very bad, Bitcoin would survive to fly another day.
However, Bitcoin development includes a very different challenge: Bitcoin operates in an adversarial system. Any network participant can trigger faults if they exist, and trusted relationships are not required to participate. Worse yet, incentives of participants are not always perfectly aligned, and participants usually have visibility into the source code of other participants (e.g. Bitcoin Core). If there are bugs, they will invariably be found.
N-Version Programming
N-Version Programming is a risk mitigation tactic where multiple entirely unique versions of a software module are created (usually by different teams and using different programming languages). For example, in a system employing Triple Modular Redundancy, the modules might be operated in parallel, and output is examined by a simple, final module which chooses the most common answer.
Similar systems employ separate, redundant Voters, also arranged in triple modular redundancy, which themselves each report their output to consuming systems. This is how the Saturn Launch Vehicle Digital Computer eliminated single points of failure.
N-Version programming is not a panacea, however. Software systems tend to encounter similar issues, software teams tend to make the same mistakes, and creating multiple versions is a lot of work. Still, there’s a place for N-version programming in certain systems.
Bitcoin is particularly well suited for n-version programming.
The system is generally quite simple (e.g. blocks are a perfect place for output validation), Bitcoin has very high reliability requirements, and the ecosystem at large has no shortage of capable developers (particularly when not limited to C++).
Defensive Consensus
Defensive Consensus is a proposal to increase Bitcoin’s reliability and software diversity by layering the security provided by alternative implementations on top of Bitcoin Core.
This consensus scheme avoids the potential for new implementations to introduce regressions while strengthening defenses against yet-undiscovered faults in Bitcoin Core. Therefore, irregularities between implementations are prevented from causing network forks.
As new implementations complete Defensive Consensus Stage 3, they become consensus-safe. The new implementation can be safely used, for any application, as a replacement for Bitcoin Core. Over time, a healthy set of bitcoin implementations will grow and evolve to provide both improved reliability and competition.
A Rollout Strategy for Alternative Implementations
Much has been written about how changes to Bitcoin’s consensus rules should be deployed.
To summarize, Bitcoin already has a completely functional consensus dispute resolution mechanism: the blockchain. Whichever valid chain has the most proof of work is the correct chain. If a number of humans decide this chain is not to their liking, they tweak their validation rules and continue building on their preferred chain. Currency competition ensues, etc.
While this mechanism works for “disputes” between implementations, it’s generally very wasteful. Miners might unintentionally mine blocks on a chain which will later be abandoned. Users might unknowingly accept transactions which do not occur on the proper chain.
Implementation inconsistencies are accidents, and the network is better off if these forks are never triggered (and instead, discovered and fixed). Defensive Consensus is an incremental strategy for rolling out this protection. Summarized, the stages are as follows:
- Stage 1: Avoid Causing Forks
- Stage 2: Avoid Following Forks
- Stage 3: Prevent Forks
Stage 1: Mining Pools Protect their Profits
Unintentional forks are not always caused by alternative implementations.
The BIP 50 Fork
More recently, in March of 2013, a seemingly benign change to Bitcoin Core’s internal database caused an unintentional blockchain fork. The change had been released in version 0.8 nearly a month earlier.
A miner running the 0.8 version mined a block which included an unusually large number of total transaction inputs. Because validating this block required a large number of database locks, older versions rejected the block, and continued mining on the previous one. Miners who had already upgraded to 0.8 automatically accepted the block as valid, and began mining on the new 0.8 chain.
To make matters worse, 60% of the mining network had already upgraded to 0.8. Without intervention, the fork would permanently create two separate networks, both with considerable mining power.
Forks are Expensive
Miners on the new fork, working with Bitcoin Core developers, decided that a long-running, accidental fork would be worse than losing the block rewards they’d mined. They downgraded to a version which would not accept the larger block, and continued mining on the old chain.
A total of 31 blocks were mined on the orphaned chain before the fork was resolved, representing a loss of 775 BTC to those miners. At today’s prices, that’s $1 million USD and over 5 hours of wasted electricity and time.
Causing a Fork is Expensive
Luckily for the network, this issue does not suffer from the tragedy of the commons. Mining a block which causes a fork is risky. This is true no matter how much hashing power is on either side of the fork. (In the BIP50 case, while the 0.8 miners were in the majority, they still incurred the loss.)
Mitigating Risk
Miners are generally incentivized to mine uncontroversial blocks: blocks which will be accepted by any and all bitcoin implementations. The safest way to mine, therefore, is to confirm that the block currently being mined, usually the candidate block, will be validated by any and all important bitcoin implementations before it is mined. We’ll call this Defensive Consensus Stage 1 (DCS1).
A small amount of additional overhead is required to maintain each additional implementation. Miners should run both old versions of Bitcoin Core and a few completely different implementations (e.g. Bcoin and Btcd). For today’s large mining pool operations, this is a very inexpensive risk mitigation tactic.
This strategy has been proposed many times over the years. Dave Collins, the primary author of Btcd (a Go implementation), wrote a great blog post with some additional detail about a pragmatic implementation using Luke Dashjr’s BIP22 and BIP23.
Stage 1 Protections
DCS1 is not a protocol change, it’s a risk mitigation tactic for miners. (It would likely also generate goodwill among members of the community interested in increased software diversity.) Stage 1 provides direct, immediate benefits to participating miners, while also making further stages much easier.
Even without Stages 2 and 3, the wide acceptance of this strategy would go a long way toward avoiding unintentional forks and improving the reliability of the bitcoin network in the future.
Stage 2: Services Prepare for All Eventualities
Creating 184 Billion BTC
In 2010, CVE-2010–5139, was discovered and exploited. An overflow bug in Bitcoin Core (a common problem in C++) allowed for an attacker to create a transaction which sent 184 billion new bitcoin to the attacker’s address. The bug was quickly fixed, and the chain without the unplanned inflation overtook the previous chain after 53 blocks, about 9 hours later.
If another bug of this nature were found and exploited in Bitcoin Core today, many services on the network would not be significantly better prepared. Particularly for smaller bitcoin companies (without round-the-clock monitoring or existing mitigation strategies), just a few hours of successful double spends could bankrupt the business.
This double spend opportunity was successfully exploited against OKPAY in the March 2013 fork (luckily, by a white hat). With a larger ecosystem, the possibility of bigger, better-organized heists of this type continues to grow.
Failing Safe
Regardless of the cause or nature of the specific fork, bitcoin services (exchanges, ATM providers, BitPay, etc.) must be prepared to handle it deliberately.
One particularly safe option is to stop processing on-chain transfers until a human has intervened. Depending on the service, other, better fail-safe modes are likely possible.
Miners running DCS1 would allow at least one chain to continue on without interruption. As well as being advantageous to the miner, this would be very helpful for services. One uncontroversial chain would remain open for business. Depending on the particular service, business may be able to continue as usual.
Until DCS1 is widely deployed, many services may choose to rely on Bitcoin Core as the single source of truth. In this case, the service may choose to enter a fail-safe mode only if multiple versions of Bitcoin Core are unable to come to a consensus on the latest block (as with the BIP50 fork).
Any service which is simultaneously running multiple implementations, and implements business logic to intelligently handle inconsistencies, could be deemed compatible with Defensive Consensus Stage 2 (DCS2).
Stage 2 Protections
Like DCS1, DCS2 is not a consensus change, but a risk mitigation strategy for important players in the bitcoin space. Adopting DCS2 as a strategy allows services to better architect themselves for unexpected Bitcoin network events. It also prepares services for DCS3.
Stage 3: Signaling and Activation
Miners and services implementing DCS1 and DCS2 strategies are likely to find minor inconsistencies between implementations. Over time, these differences will be smoothed out, and general trust in the alternative implementations will grow.
Occasionally, alternative implementations may be deemed important enough to elevate to Defensive Consensus Stage 3. These implementations are significantly different than any other implementations in the consensus critical set (currently, only the past few releases of Bitcoin Core).
A BIP9 signaling process should activate enforcement of the new implementation, requiring that new blocks be acceptable to each implementation before they are considered valid. Blocks which are considered invalid by one implementation (at this point, almost certainly malicious) will be orphaned by DCS3 compliant miners.
By allowing consensus to be enforced by a redundant set of implementations, we significantly reduce the chance of faults, network-wide vulnerabilities, and unintentional forks. Additionally, all implementations in the consensus critical set become consensus-safe: they provide a reliability guarantee equal to that of Bitcoin Core, suitable for most end users.
With a DCS3 “path to production”, implementations can even be written in languages designed for formal verification, like Agda, Coq, Idris, or Lean. Without Defensive Consensus, these advances in computer science may take significantly longer to apply to the C++ Bitcoin codebase.
Summary
This posts aims to provide the background, motivation, and a brief summary of a bitcoin consensus strategy called Defensive Consensus.
Defensive Consensus is a proposal to increase Bitcoin’s reliability and software diversity by layering the security provided by alternative implementations on top of Bitcoin Core.
This strategy reduces risks for miners, services, and end users, while enabling faster, more open, and less political development in the bitcoin ecosystem.
To the extent that well-meaning changes to Bitcoin are resisted due to implementation uncertainty, Defensive Consensus offers a safer path. (Consider SegWit, Xthin, Drivechain, etc.)
Defensive Consensus allows alternative implementations to shield the network from implementation faults in the C++ implementation. This could allow us to safely re-enable Bitcoin Script’s disabled opcodes and loosen standard transactions.
Finally, Defensive Consensus provides a roadmap for new implementations to be elevated to the same reliability guarantees as Bitcoin Core.
What’s Next
If these ideas interest you, take a look at the Bcoin and Bitcore projects. If you have questions or ideas for how this can be improved, please send me a message on Twitter.
Learn More
The following article provides some concrete examples of Defensive Consensus in action, with more detail on the system:
Please share this post if you found it interesting. Thanks for reading!