Defensive Consensus: a Concrete Example
Imagine three different implementations of “Simple Bitcoin” exist: Europa, Ganymede, and Callisto.
Imagine three different implementations of “Simple Bitcoin” exist: Europa, Ganymede, and Callisto.
In Simple Bitcoin, “blocks” consist of a single capital letter. Simple Bitcoin has only one rule for validating blocks: a block must be either the letter B or the letter C.
Since each implementation contains bugs, this is easier said than done. Obscure bugs mean that for each implementation, there is at least one other letter which the implementation would consider valid. (The developers of Callisto even insist that A should also be valid, but they haven’t really convinced the rest of the community.)
If we were somehow able to understand each implementation completely, and if we were able to list every block each implementation would accept, the list might look as follows:
- Europa:
B,C,Z - Ganymede:
B,C,CD - Callisto:
A,B,C,CD
Our goal is for a network composed of these implementations to run in perfect synchronization, with no risk of accidental forks.
Defensive Consensus Stage 1 (DCS1)
A naive solution is for miners to run whichever implementation they like best, hoping that the miners running the other implementations don’t leave them behind in an accidental fork. While it might work (for some definitions of the word), it would also occasionally cause disruptions and expose participants to fraud risks.
A better solution is for miners to run in a Defensive Consensus.
Before mining a new block, the miner ensures that the candidate block is considered valid by each implementation. When the miner finds a nonce and broadcasts the block, they can be sure that other miners will mine on their block.
The miner already checked the validity of the block template against all implementations before mining the block, so the new block is guaranteed to be valid for all implementations. For convenience, we call this Defensive Consensus Stage 1 (DCS1).
Let’s look at each case.
Miners not running DCS1 risk losing their block reward and mining on an unintentional fork if they mine any of the following blocks:
- Europa miners:
Z - Ganymede miners:
CD - Callisto miners:
A,CD
The Z Fork
Europa was the first Simple Bitcoin implementation, and nearly 100% of the miners are still using it. It’s fast, reliable, and battle-tested.
However, Europa is written in C++, and Europa’s code quality leaves something to be desired. Over the years, a subtle overflow bug has gone unnoticed, allowing Z blocks to be validated by Europa. Z blocks allow an attacker to create 184 billion new bitcoin for themselves.
Obviously, this is a major bug in Europa (CVE-2010–5139). Worse yet, it’s been there since the beginning of Simple Bitcoin, so almost 100% of miners are running a vulnerable implementation. This is the worst kind of bug: it will need to be fixed, and the blockchain will need to be rolled back. Nearly all bitcoin users are vulnerable to payment fraud for the duration of the fork.
Europa Miners
Miners who are exclusively mining using Europa’s validation rules are the hardest hit by this bug. They lose all the work they did by mining on the bad chain: approximately 53 blocks, or 2,650 BTC at the time.
Ganymede and Callisto Miners
This was a lucky break for miners using alternative implementations. When these miners received the Z block, they immediately threw it away, since to them, it was not valid.
While normally it’s a terrible idea to mine with a different implementation than the majority of the network, in this case, the miners made out without losing their work. They continued a valid chain, and when the bug in Europa was fixed, the Europa miners rejoined their chain.
DCS1 Miners
Because the network hasn’t advanced to multi-implementation DCS3 (described later), the DCS1 miners fared only slightly better than the Europa miners.
Because DCS1 miners only mine candidate blocks which are valid for all implementations, they never attempted to mine the Z block themselves. However, since they know Europa is still the only consensus-safe implementation, when the Europa miners continued mining on the bad chain, they followed.
For this case, the DCS1 miners only saved the first 10 minutes of wasted mining. (Nevertheless, 50 bitcoin is 50 bitcoin.)
The Z Fork in an Alternate Reality
You might wonder why the DCS1 miners wouldn’t have followed the Ganymede and Callisto miners when the Europa miners started mining controversial blocks (blocks not accepted by all implementations).
While in this case, things worked out for the alternative implementations, often they will not. Rolling back the blockchain is a major event which creates payment fraud risk for the entire network. More often, the consensus differences between Europa and the other implementations will be subtle, and not have such a significant impact on end users.
In these cases, the Europa miners are likely to continue onward. Even if it creates particularly ugly baggage for Simple Bitcoin, Europa developers are pragmatic, and the show must go on.
“Z is now a valid block. Z has always been part of the protocol.”
Europa Miners
This is obviously the best case for Europa miners, as they don’t need to do anything. As an added benefit, non-Europa miners just got knocked off the chain. In a sense, the Europa miners are making overtime pay.
Ganymede and Callisto Miners
Conversely, the Ganymede and Callisto miners are kicking themselves for trying to fight Europa. They need to either update their implementations to accommodate Z block or (better yet) wise-up and switch to Europa (or DCS1). Meanwhile, their ASICs stay cold and their wallets empty.
DCS1 Miners
Miners employing the DCS1 strategy fared the same as the Europa miners. When the fork occurred, because Europa is currently the only consensus-safe implementation, DCS1 miners stopped checking their blocks against the other implementations, and built on the Europa-only chain.
The CD Fork
Another inconsistency arrises between the implementations.
Both the Ganymede and the Callisto implementations use different databases than the one used by Europa. No one thought this was an issue until it was discovered that a technical detail of Europa’s database prevents certain kinds of C blocks from being validated. The C blocks not recognized by Europa became known as CD blocks.
Ganymede and Callisto are both very popular, used by over 60% of the network. Though a majority of the hash power supports all C blocks properly, the bug in Europa still presents an interesting problem.
Almost 40% of the network is still using Europa, and probably cannot upgrade quickly. The CD miners have two choices:
- Ignore the fork, and continue mining with the 60% hash power, or
- Revert back to the Europa chain, and stop validating
CDblocks.
In the first case, a long, contentious fork is very possible. The Europa side is unable to upgrade, and the longer the fork goes on, the more each mining faction has invested in their respective side. At the same time, the network has suddenly split in half, and payment fraud is now possible against users and services which are not aware or able to process both forks.
While the CD miners could choose the scorched-earth policy of continuing (here again, they’re receiving overtime pay), this could seriously hurt the value of their capital investments by hobbling the network for an indefinite amount of time (probably also reducing the price of bitcoin).
The Ganymede and Callisto miners quickly choose to invalidate CD blocks.
Europa Miners
In this case, the Europa miners get the lucky break. The chain they’ve continued to mine is the one on which the network settles.
Ganymede and Callisto Miners
The Ganymede and Callisto miners drew the short straw in this fork. The work they invested in the invalid chain gets thrown away.
DSC1 Miners
Again, the DCS1 miners were on the right side of blockchain history. They continued mining on the Europa fork, since Europa was still the only consensus-safe implementation. (DSC3 has not yet activated, so the safe option is still the most-backwards-compatible version of Europa.)
Had the Ganymede and Callisto miners been using DCS1, this fork would not have happened. Even with only some DCS1 miners, the fork could have been less damaging, and perhaps even broken into a few shorter forks. (DCS1 provides a degree of herd immunity.)
In Another Galaxy
There will likely be cases in which the Ganymede and Callisto miners might choose the scorched-earth approach. We’ll look at how DCS3 can eliminate risks for all miners (and the network at large) below.
Defensive Consensus Stage 2 (DCS2)
For each of these forks, many other network participants experienced serious disruptions.
Large actors in the Simple Bitcoin space, exchanges, ATM operators, payment processors, etc., would also be wise to employ a defensive consensus risk-mitigation strategy. (If they do not do so already.)
For convenience, when a service is capable of employing this strategy, we’ll call it Defensive Consensus Stage 2 (DCS2) compliant.
Generally, this would look similar to DCS1-compliant miners.
Services employing DCS2 validate across each implementation when performing functions which rely on network state. Business logic for the service can take risk into account, and functions which are too dangerous to operate in uncertain network conditions can fail safely.
If a divergence occurs between implementations, the service should fall back to a consensus-safe implementation, currently, Europa.
Defensive Consensus Stage 3 (DCS3)
BIP9 activated forks are the final stage in this rollout strategy for Defensive Consensus.
In Defensive Consensus Stage 3 (DCS3), miners signal for and activate the inclusion of well-established implementations into Simple Bitcoin’s defensive consensus. Implementations which make it through activation can be collectively called the consensus-critical set.
At this stage, if a block is invalid for any implementation in the consensus-critical set, it is not added to the chain. Given a consensus-critical set of the previously mentioned clients, each fork discussed above could be avoided.
Each implementation added to the consensus-critical set decreases the potential set of valid blocks. With an adequate number of implementations, and especially with the constant improvement of each implementation, this set approaches our stated goal.
Given our initial assumptions about Simple Bitcoin, we can be confident that our Defensive Consensus now only allows for blocks B and C.
Feedback?
If you have questions or ideas for how this can be improved, please leave a comment or send me a message.
Please share this post if you found it interesting. Thanks for reading!
Previous Post
bitjson