This is a two-piece, Part 2 of which outlines a framework for allowing Nakamoto Consensus to solve the challenges described in this article. It can be found here.

There was, and still is, a lot of heated discussion about the circumstances of the recent BCH hard fork. Most of this has been about the merits of the different proposals that various dev teams have been planning, and I’m not confident enough in my knowledge of the technicalities of these proposals to present any definitive conclusions about them. What I feel I can say something about, is an idea some people used to handwave others’ concerns over the hard fork causing a permanent Chain Split.

“This will all be settled by Nakamoto Consensus”

As we now know, this didn’t happen. The chains diverged, and the split was decidedly permanent less than an hour after the so-called “hashwar” started.

The whitepaper mentions this about the mechanism later named Nakamoto Consensus:

“Any needed rules and incentives can be enforced with this consensus mechanism.” - Bitcoin Whitepaper, Section 12

This quote has lead a lot of people to erroneously believe that the same mechanism can be used to settle any dispute regarding the system that creates the blockchain, using the current implementations. This is not currently possible, and describing the various types of splits that can happen is actually enough to show that. We’ll go through them in order of complexity.

Ledger Splits

A Ledger Split happens when more than one miner mine a new block at roughly the same time, and those blocks are competing for the same position in the blockchain. Since every other miner will initially start mining on the first block they validate, this sometimes leads to a situation where there are two (or more) competing transaction histories, or Ledgers. From the place in the chain the competing blocks were created, until the competition is resolved, the blockchain is split. Eventually one of the splits gets more blocks built on top of it than the others, because it has more computing power (hashrate) behind it. The current implementations have a mechanism for acknowledging when that happens and will automatically Yield their own hashrate to support the longest chain and discarding the block(s) that lost the race. This is the essential definition of Nakamoto Consensus; using hashrate to solve disagreements in a proof-of-work based blockchain system. It works with Ledger Splits because, and only because, the only difference between the splits are which transactions are included in which blocks. The rules those transactions, and the blocks that include them, must follow are the same for every competing block. Every transaction and block validate according to the same ruleset, and thus an implementation can easily switch to another Ledger if it notices that more blocks are being built on it. Additionally, the end user rarely notices this happening, since normally all transactions sent to the network are included in all competing Ledgers.

Soft forks and Hard Forks

Whenever a change to the protocol’s ruleset is made, it is introduced as either a Soft or Hard Fork. To understand the difference between the two, I really recommend Mike Hearn’s brilliant piece On Consensus and Forks, but I’ll describe the gist of it here.

If the “new” ruleset is stricter than the “old”, then any block following the “new” rules will by definition also follow the “old” ones. This means that any miner validating according to the “old” rules will accept a block created using the “new” ones as valid.

If the “old” ruleset is expanded to include functionality that wasn’t previously allowed, for example such as a new address format or transaction type, it is essentially a Hard Fork. In this case, miners running clients that validate according to the “old” ruleset will stop accepting blocks from the network as soon as another miner creates a block that takes advantage of the new functionality, and so with Hard Forks it is very important that a vast majority of the network’s hashrate has updated their clients to use the “new” rules.

Of course, it is possible to implement ruleset expansions with a bit of trickery, so that new functionality is still valid according to the “old” rules, and thus it is possible to introduce a ruleset expansion as a Soft Fork. This is what was done with BTC’s Segregated Witness; a new transaction type was made to use the previously accepted “Anyone Can Spend” address type. This address type doesn’t need any signature data to be spent, and thus “old” miners were tricked into accepting SegWit transactions without really knowing what they were validating. Since a vast majority of the BTC network’s hashrate was validating according to the “new” rules, this was not a problem; had they not then literally anyone could’ve spent any coin sent to a “SegWit” address, because the Nakamoto Consensus would’ve decided that the “SegWit” addresses were still “Anyone Can Spend” addresses.

In terms of Nakamoto Consensus, changes in the ruleset imply that the mechanism only works one way. With Soft Forks, old clients will automatically accept the new ruleset, but new clients may end up rejecting the old rules, because they may no longer be valid. This is the reason SegWit needed such a vast majority of miner support before Core dared to activate it. In order to implement it as a Soft Fork, they had to change the use of the already existing “Anyone-Can-Spend” address format, and if not a vast majority of the network followed along with the update, the network could have split between the miners who validated according to the SegWit ruleset, and the miners who ignored the external witness data and accepted those transactions as “Anyone-Can-Spend” outputs, allowing literally anyone to spend any money sent to a SegWit address. With Hard Forks, new clients are usually compatible with the old ruleset and can give up if the old chain gets more POW, but old clients will simply stop syncing with the network if their ruleset loses hashrate, because they are unable to validate the new rules. Had SegWit been introduced as a hard fork, we could in theory have allowed Nakamoto Consensus to decide whether to actually activate it.

Chain Splits

Sometimes, different development teams propose very different ruleset changes, and are unable to come to agreement about one ruleset that works for both. This has happened several times in the history of Bitcoin, but most notable was the permanent Chain Split that resulted in BTC and BCH in August 2017. After years of debate, a handful of developers created a Bitcoin client that would Hard Fork to an 8MB capacity limit per block and reject the proposed SegWit transaction type as invalid. Likewise, the BTC protocol update that happened a few weeks later included SegWit transactions, and still rejected blocks bigger than 1MB. Since these two rulesets were mutually incompatible, neither implementation was capable of Yielding to the ruleset of the other, and thus the Chain Split was permanent.

Coming back to the quote from the Whitepaper:

“Any needed rules and incentives can be enforced with this consensus mechanism.” - Bitcoin Whitepaper, Section 12

The emphasis here is on “can”. It is completely within the realm of possibility to solve all these issues using hashrate, but currently only in theory.

In Part 2, which will hopefully come out sometime next week, I will try to lay out a proposal for how we can make practical use of this principle.