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.

An example of Triple Modular Redundancy. The final output is a majority decision of three redundant logic gates.

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 ♡ and share this post if you found it interesting. Thanks for reading!