For Bitcoin to work, all users must agree on a history of transactions (the blockchain) and on a set of fundamental rules defining what is accepted on this blockchain and what is not accepted on this blockchain. When this consensus cannot be reached, the user community can be divided into two distinct networks, each with its own rules. This is precisely what happened in 2017 during the hard fork that gave birth to Bitcoin Cash (BCH).
But how did we get there? In this article, I invite you to relive this period of conflicts within the Bitcoin community, known as the “Blocksize War”, in order to understand how this debate has permanently shaped the ideology of bitcoiners.
The origin of the conflict
The Blocksize War originated in a technical debate about Bitcoin's ability to handle an increasing volume of transactions. This is sometimes called “scalability” or “scaling up.” As it is adopted as a payment method, Satoshi's invention must be able to handle the transactions of new users, while maintaining reasonable fees.
Among these technical limitations that reduce the flow of transactions, there is obviously the block size limit on the blockchain. The larger the blocks, the more transactions that need to be confirmed can be included.
When it was launched in 2009, Bitcoin did not have an explicit limit on this size. However, in 2010, Satoshi Nakamoto introduced a limit set to 1 megabyte (via the constant MAX_BLOC_SIZE). The purpose of this modification was to prevent transaction spam attacks and to ensure a certain decentralization of the network by preventing excessively large blocks from monopolizing the resources of node operators.
At the time, the size of 1 MB was more than enough to support the low number of transactions on the network. However, as Bitcoin grew in popularity, the community started to debate the need to increase this limit to allow for better management of transaction volume without fees soaring. This is how a first rift emerged within the Bitcoin community. Some, who would later be called “big blockers,” believed that an increase in block size was a simple and straightforward solution to solve congestion problems. In contrast, others, who will be referred to as “small blockers”, argued that this approach risked centralizing the network by increasing the hardware requirements of the nodes.
Indeed, since each complete node must check and then store the entire blockchain in memory, larger blocks require larger capacity disks, which is more expensive and reduces the incentives to run its own node. If there are fewer Bitcoin nodes, system security is less well distributed, increasing individual risks of coercion by focusing security on a smaller number of actors.
These discussions about block sizes are even older than the 2015-2017 period. In reality, as early as 2010, proposals had already been made to increase the limit, such as The patch proposed by Jeff Garzik.
But it was really from 2015 that the debate would turn into a conflict, with a first offensive on the part of the developers of Bitcoin XT, an alternative client launched by Mike Hearn and supported by Gavin Andresen (former main maintainer of Bitcoin following the departure of Satoshi Nakamoto). Bitcoin XT was originally an implementation of the Bitcoin protocol compatible with Bitcoin Core. However, in August 2015, version 0.11A of Bitcoin XT adopted BIP101: a hard fork that immediately increases the block size limit from 1 MB to 8 MB, with the addition of a mechanism to double this limit every two years, until reaching just over 8 GB per block in 2036. In fact, the Bitcoin XT nodes have therefore separated from the rest of the Bitcoin network. This tour de force is considered by many to be the casus belli of block-size warfare.
Small blockers versus big blockers
The Blocksize War conflict was structured around two opposing camps: the “big blockers” and the “small blockers”, each defending a different approach to solving the Bitcoin scalability problem.
The “big blockers” were in favor of increasing block sizes, in order to allow Bitcoin to process a greater number of transactions. For them, such an approach was needed to reduce transaction fees and improve the user experience as Bitcoin grew in popularity. They also maintained that this solution was technically simple to implement via hard forks. In particular, the “big blockers” were supported by early developers, such as Gavin Andresen, Jeff Garzik, Mike Hearn, and influential players such as Roger Ver and the majority of mining companies. For them, the increase in block size was synonymous with an increase in their revenues. Indeed, if you can put more transactions in each block, you can also collect more fees.
In contrast, the “small blockers”, mainly represented by Bitcoin Core developers such as Pieter Wuille, Wladimir van der Laan, Peter Todd, Gregory Maxwell, or Luke Dashjr, were more conservative in their approach. They argued that increasing block size would pose risks of network centralization, as it would place a heavier load on the nodes, which would limit the distribution of risks. The “small blockers” also wanted Bitcoin to be able to scale, but they preferred scalability solutions that moved transactions away from the main blockchain, such as the Lightning Network for example. The idea was to manage a large volume of transactions without changing the basic protocol to preserve the decentralization of the network, and therefore the distribution of its security. Small blockers also prefer conservative changes made through soft forks rather than hard forks.
The technical debate between these two visions of scalability has deeply divided the Bitcoin community. Each camp mobilized propaganda and influence strategies to try to get their ideas across.
Forks' proposals and attempts
Forks' attempts and proposals multiplied between 2015 and 2017. As we have seen, the first real fork attempt during the Blocksize War was that of BIP101 on Bitcoin XT. This proposal was supported by a large number of miners, and by companies that were influential at the time such as BitPay, Blockchain.info or Circle. Eventually, Bitcoin XT won't be able to get enough support from the community, and Mike Hearn will eventually announce his departure and the sale of his bitcoins. He will express his disappointment in a blog post where he will state in particular that” Bitcoin failed ”. Bitcoin XT thus marked the start of deep differences in the community, and other forks soon followed.
In early December 2015, Pieter Wuille and Gregory Maxwell, developers of Bitcoin Core, proposed a soft fork called “SegWit” (Segregated Witness). This proposal aimed to separate signature data from transaction data in the blockchain, in order to solve the problem of transaction malleability. This problem, linked to ECDSA, the digital signature algorithm used on Bitcoin since 2009, makes it possible to slightly modify a valid signature to create another valid signature for the same transaction. This vulnerability prevented the Lightning Network from being implemented. Maxwell and Wuille's intention with SegWit was therefore to enable a secure deployment of the Lightning Network, and thus to solve Bitcoin's scalability problems. SegWit also included a slight and virtual increase in block size, while remaining compatible with the old nodes (soft fork). This proposal quickly became the spearhead of small blockers.
However, following the failure of Bitcoin XT, Gavin Andresen and Jeff Garzik came back a few weeks later with a new idea: Bitcoin Classic. Proposed in early 2016, this fork suggested a more moderate and consensual approach than Bitcoin XT, with an increase in block size to 2 MB (via BIP109). The initiative was supported by numerous companies in the sector such as Coinbase as well as by miners.
As Bitcoin Classic grew in popularity and threatened to split the network, an emergency meeting was organized on February 20, 2016: the Hong Kong Roundtable. This event brought together miners (including Jihan Wu and Micree Zhan, the co-founders of Bitmain), some influential companies, and Bitcoin Core developers (including Luke Dashjr, Matt Corallo, and Peter Todd). After long hours of negotiation, an agreement was reached. Core developers are committed to implementing a hard fork for SegWit as well as doubling the block size limit. For their part, miners and businesses promise to support this fork and exclusively use the Bitcoin Core client, in order to preserve the unity of the Bitcoin network.
This deal was supposed to end the Blocksize War, but it ultimately created more conflicts. Each side interpreted the agreement differently and it will ultimately never be implemented.
Some external events also weakened this agreement, in particular the hack of The DAO on Ethereum, which led to a hard fork to recover the stolen funds, thus causing the split between ETH (Ethereum) and ETC (Ethereum Classic). This hard fork proved to be a disaster for Ethereum, in particular because of the replay attacks that disrupted the entire industry (transactions from one blockchain could be rebroadcast identically on the other blockchain). This fiasco highlighted all the risks that a hard fork could pose to Bitcoin, and therefore provided an important argument for small blockers, who found themselves in a position of strength. At the same time, other events have tarnished the reputation of some big blockers, which has reduced their credibility with the community. This Hong Kong agreement still had the merit of curbing the momentum of Bitcoin Classic.
Small blockers take advantage of this reputation to launch SegWit reporting alone, by setting up that the soft fork is activated if 95% of the computing power approves it over a given period of time. However, during the first few weeks, reporting remains low and minors do not seem to want to cooperate. At the same time, a new fork proposal is gaining popularity with Bitcoin Unlimited. This alternative client, promoted in particular by the entrepreneur Roger Ver (nicknamed “Bitcoin Jesus”), proposes to increase the size of the blocks in a flexible way via a hard fork. Unlike Bitcoin Classic, Bitcoin Unlimited does not set an upper limit on block size, allowing users to set their own settings.
It was under the threat of this new fork that BIP148 was published in March 2017 by an anonymous developer calling himself Shaolin Fry. The objective of BIP148 is to force the activation of the SegWit update on the Bitcoin protocol, in the face of the stagnation of the signaling of this soft fork by miners via the classic BIP9 method. To achieve this, he proposes the implementation of a UASF (User-Activated Soft Fork), in order to forcibly activate SegWit by the nodes on November 15, 2017, if the miners had not locked SegWit by August 1, 2017. If BIP148 is followed by users, Bitcoin network nodes will refuse blocks that do not signal support to SegWit, putting pressure on miners to adopt the update.
The community sees this UASF proposal as an opportunity to finally bring down the big blockers and is therefore beginning to actively support it. Clothing with the acronym UASF is appearing at conferences and communication is intensifying on Twitter.
Faced with the threat of the UASF, the big blockers are forced to return to the discussion table despite their position of strength following the failure to report SegWit. Thus, on May 23, 2017, a new private meeting was organized in New York, on the sidelines of the conference Consensus 2017, bringing together more than 50 companies from the Bitcoin ecosystem. From this meeting was born the Segwit2x proposal, which foresees two major changes to the Bitcoin protocol:
The adoption of SegWit with an activation threshold set at 80% signaling;
A hard fork to increase the maximum block size from 1 MB to 2 MB.
James Hilliard (engineer at Bitmain) then proposed BIP91 to facilitate the activation of the SegWit soft fork, defined in BIP141, BIP143 and BIP147, via an 80% MASF. This method aims to make BIP148 (UASF) obsolete and to avoid a potential blockchain split on August 1, 2017. BIP91 was finally activated on July 23, 2017 (at block 477,120), just before the critical date of August 1 set by BIP148. This makes it possible to force the reporting of SegWit by minors, which will finally be locked on August 9 at block 479 808, then activated on August 24 at block 481 824.
So the UASF never happened, but it played a decisive role in the adoption of SegWit by forcing miners to lock the soft fork via BIP91. In the longer term, BIP148 set an important precedent, demonstrating the influence that users can exert through their full nodes on Bitcoin protocol governance decisions, even if big businesses and miners disagree.
In parallel with the activation of SegWit, on August 1, 2017 at block 478 559, part of the Bitcoin community is carrying out a hard fork to increase the block size to 8 MB. This split, called Bitcoin Cash (BCH), still exists today alongside Bitcoin, although its valuation is very low in comparison.
After the activation of SegWit, the second part of Segwit2x still had to be implemented at block 494 784, i.e. during the month of November 2017, via a hard fork intended to double the size of the blocks. However, small blockers strongly opposed this update, especially because it was a hard fork without all the necessary security mechanisms. A new communication campaign, called” NO2X ”, then emerged to prevent this increase in block size. On November 8, the hard fork was finally abandoned at the last minute, due to a lack of consensus and in the face of community rejection. This date is often considered to mark the end of the Blocksize War.
This episode of the Blocksize War undeniably left a mark on the Bitcoin community. What started as a simple technical debate gradually turned into a conflict that could have endangered the very existence of Bitcoin, or at least significantly weakened it. This period also profoundly influenced the way protocol evolutions were designed: today, a majority of bitcoiners prefer a cautious and conservative approach to updates, favoring soft forks over hard forks, even if that complicates the process. Moreover, the ideology of small blockers is now widely accepted by users.
The Blocksize War also set a precedent, by showing that the UASF could be a powerful deterrent tool to allow users to maintain their power in the face of miners and major players in the industry.
To deepen this subject of Blocksize War, I advise you to read the book The Blocksize War by Jonathan Bier, whom I used to write this article.
.png)
.png)
.png)
.png)
.png)
.png)
