Jonathan Bier - The Blocksize War: The battle for control over Bitcoin’s protocol rules

1. First Strike
2. March To War
3. Scaling I - Montreal
4. Scaling II - Hong Kong
5. SegWit
6. Lightning Network
7. Bitcoin Classic
8. Hong Kong Roundtable
9. Faketoshi
10. The DAO
11. Scaling III - Milan
12. Bitcoin Unlimited
13. Exchanges
14. ASICBoost
15. Dragons Den
16. Litecoin
17. User-Activated Softfork
18. New York Agreement
19. Bitcoin Cash
20. SegWit2x
21. Victory

It was Saturday, August 15, 2015, when an event occurred that took many in the Bitcoin space by surprise and shook the community to its core. Two of the most prominent and respected Bitcoin developers at the time, Mike Hearn and Gavin Andresen, had respectively released and thrown their support behind a new, incompatible version of Bitcoin. This new client was called Bitcoin XT. Bitcoin had offered such hope, excitement and opportunity to many, and it now appeared as if this act was sure to send the system into disarray, peril and potential catastrophe. As the Guardian newspaper said on the following Monday:

The Bitcoin wars have begun

On the surface, the war appeared to be centred on just one reasonably narrow issue, the maximum size limit for the blocks which make up Bitcoins blockchain. Bitcoin XT was a proposal to increase the amount of space available in blocks. In 2015, the blocksize limit was 1 MB and Bitcoin XT wanted to increase this limit to 8 MB and then double it every two years until 2036, when the limit would be around 8,000 MB. The reason for this was that blocks were becoming larger as the system became more popular, and the blocksize limit was close to being reached, which would result in full blocks. Proponents of the increase argued that higher capacity was needed to ensure Bitcoin could scale up and become a cheap global payments system. They were concerned that, if the limit was regularly reached, this would make the network difficult to use and too expensive, which would damage the growth prospects for the system. To Gavin and Mike, we were heading into a crisis, where users could be turned away from the network, and action was required. Gavin and Mikes opponents were concerned by the release of the incompatible client, fearing it could split the network into two, causing chaos and confusion.

This war over the blocksize would shatter and split the ecosystem over the next two years. As the war progressed, it emerged that the struggle was perhaps more complex than just the maximum size of blocks; the battle went right to the core of Bitcoins DNA. The contention was essentially about four somewhat interrelated issues:

1. The level of blockspace available in each Bitcoin block - Essentially, whether the eventual state should consist of surplus capacity available in the blocks, or consistently full blocks.
2. How to modify the rules of the Bitcoin protocol - Whether the rules on the validity of Bitcoin blocks should change relatively easily, or whether they should be more robust and only change in exceptional circumstances, with broad support from all interested parties.
3. The significance of the nodes of ordinary users - The extent to which, if any, validating nodes of the ordinary end users had a say in enforcing Bitcoins protocol rules.
4. Time preferences - Whether Bitcoin was like a tech startup which should prioritise gaining market share in the short term; or if it was a long-term project, a new global money, and one should think decades ahead when making decisions.

At this point, however, most of the focus was on the narrow issue of the blocksize limit. There was almost universal agreement in the community that the 1 MB limit was too small. However, there was no consensus on what it should be or how to change it. Most people also seemed to agree that the proposed increase in Bitcoin XT was too aggressive and that something more moderate was required.

The opening move in this war was made by Mike and Gavin, part of the so-called large blocker camp in the conflict. They had to make the first move; after all, their opponents were in favour of the status quo. Mike and Gavin had made this proposal several months back, however, it is in August 2015 when the client was officially released and they encouraged people to run it, therefore this is when we mark the formal commencement of hostilities. This is not to say Mike and Gavin considered what they were doing as a hostile act or acted nefariously; a war is merely how I am framing it in this book.

Bitcoin XT was a software implementation of Bitcoin Improvement Proposal 101 (BIP 101), one of many in a long line of proposals to increase the blocksize limit. This proposal was first formally published by Gavin Andresen, a few months earlier on June 22, 2015. The software could not just simply increase the limit; it needed an activation methodology, a system to try and ensure that the Bitcoin network itself adopted the new rules. The chosen activation methodology in this case consisted of a flag day and a miner signalling threshold. The earliest activation point was January 11, 2016, around five months away. In addition, activation required a vote from the Bitcoin miners. Miners would be required to signal inside the blocks they produced that they had upgraded for the proposal. If 750 blocks flagged support, in any 1,000-block rolling window, the upgrade would activate. After this, there would be a two-week grace period before the rule came into effect and the blocksize limit finally increased. If miners did not achieve this 75 percent threshold, the proposal would be considered a failure.

The Bitcoin XT software was extremely controversial inside the so-called small block camp, primarily because it was an incompatible upgrade to the network. What this essentially means is that anyone running a Bitcoin node that validates all the rules would be required to upgrade their software. If everyone did not agree to upgrade, according to the small block world view, this could cause Bitcoin to split into two different coins. This type of upgrade is referred to as a hardfork, the most extreme form of upgrade possible. This type of upgrade can essentially change Bitcoin in any way, from increasing the Bitcoin supply cap above 21 million, to taking away any coins from any holder and giving it to anyone else. Many Bitcoiners had a preconceived idea that one cannot, or shouldnt, conduct a hardfork without first ensuring there is widespread support across the users of the network. To them, this characteristic is what made the network resilient; it meant nobody could take away their coins and ensured the supply cap of 21 million was robust. This was considered as the whole point of Bitcoin. Pushing for a hardfork without consensus was therefore considered by some as an attack on the network. Others clearly did not agree; they thought that Bitcoin needed to be flexible in order to succeed and grow and, with respect to the particular matter in question, the blocksize limit, this was not a major change. They considered bringing up the 21 million supply cap was merely an example of the slippery slope fallacy, and a red herring.