Blocksize War

Imagine two everyday needs. Anna wants to send bitcoin without a long wait or a high fee. Pavel runs a full node: a computer that checks blocks and transactions for itself. He wants to verify his money without expensive equipment. Both needs make sense, but more data in every block also means more data to transmit and check. The balance between them lay at the heart of the Block Size War. A block is a batch of transactions added to the network’s shared payment history. Anna and Pavel are illustrative characters. The actual debate of 2015–2017 involved developers, mining operators, exchanges, wallet providers and users. They disagreed about capacity and about how to introduce a change safely. Bitcoin had no chief executive who could choose an option and order everyone to switch. [1] [11] [13]

Before SegWit, the rules limited a block to 1 MB, or 1 000 000 bytes. This was not a fixed number of payments: transactions take up different amounts of space. A new block arrives roughly every ten minutes on average. When demand for space exceeds capacity, miners generally prioritize transactions offering higher fee rates, leaving others waiting. Larger-block advocates wanted to add room directly on the base network and keep payments affordable. Opponents worried about bandwidth, computer requirements and timely block propagation. If fewer people could verify independently, more users would have to trust outside services. Raising the limit alone would neither produce blocks faster nor guarantee permanently low fees. Demand and actual use of the space would still matter. [1] [2] [13]

A developer can write new software. A miner can use it to produce a block. But a Full Node operator chooses the rules their node checks. Even a majority of computing power cannot make an unchanged node accept a block that breaks its rules. Mining power helps select among valid chains; it cannot turn an invalid block into a valid one. This does not give every node one vote in a worldwide ballot, nor let one person prevent others from leaving. Businesses choose what to accept, miners what to mine and users what to value. Incompatible rules can lead to two networks. An industry agreement could therefore support a change, but could not automatically rewrite everyone’s software and decisions. [11] [12]

The proposals were documented as BIPs, short for Bitcoin Improvement Proposal. A BIP explains a proposal so that others can examine and discuss it. Receiving a number does not mean the network has adopted it. In BIP 101, Gavin Andresen proposed raising the limit to 8 MB, followed by growth on a predetermined schedule. The proposal called for an approximate doubling every two years and specified activation conditions. Mike Hearn and Andresen advocated Bitcoin XT, alternative software offering this approach. Publishing the program, however, was not the same as changing the entire network’s rules. Old nodes would reject blocks larger than the existing limit. This was a Hard Fork: a change expanding the set of permitted blocks, whose recipients would need different rules. The debate thus moved beyond how much room to add. Who would switch, how would they coordinate, and what would happen if a substantial group disagreed? [1] [18] [13]

Eric Lombrozo, Johnson Lau and Pieter Wuille described another approach in BIP 141. SegWit reorganized transaction data and introduced block weight, capped at 4 000 000 weight units. The witness portion contains data used to verify spending authorization. That data did not disappear or stop being checked; it received different treatment in the weight calculation. Capacity depends on the mix of transactions, rather than simply allowing ordinary four-megabyte blocks. Weight is a way of counting data against the block limit: a byte of base data counts as 4 units, while a byte of additional witness-related data counts as 1. Transactions with the same size in bytes can therefore use different amounts of the allowed weight. Capacity also depends on the types of transactions people use. For eligible transactions, SegWit also removed the ability to change their identifier by altering signature data. This made it easier to build the payment channels underlying the Lightning Network. SegWit was designed as a Soft Fork: newly valid blocks fit the old rules, although older nodes do not check every new restriction. Bitcoin Core 0.13.1 included the activation mechanism; releasing the software did not itself turn SegWit on. [2] [3]

On 23 May 2017, Digital Currency Group published the New York Agreement, an agreement among companies and miners. It paired support for SegWit with a commitment to a 2 MB Hard Fork within six months. This second step became known as SegWit2x, implemented by the btc1 project. Some participants saw an acceptable compromise: each side would get part of what it wanted. Others opposed both the second change and the way it was being pursued. A company’s support did not automatically represent all its customers’ consent. Bitcoin Core later explicitly warned that btc1 was not a required upgrade to its software and that supporting SegWit did not mean supporting SegWit2x. When reading reports from the time, remember that two changes in one agreement remained two separate rule changes. [6] [7] [11]

The pseudonymous author Shaolin Fry proposed BIP 148, a UASF, or user-activated Soft Fork. Starting on 1 August 2017, measured using Median Time Past, nodes enforcing it would reject blocks that did not signal SegWit unless it was already locked in or active. If mining and block acceptance diverged, the network could split. This was not a risk-free switch controlled by all users together. Median Time Past is the middle value after sorting the timestamps of the last 11 blocks, rather than the time on each user’s clock. Signaling here meant a marker in a block header expressing the miner’s support for that deployment; the marker did not itself switch on the new rules. James Hilliard’s BIP 91 described miner coordination at a lower threshold: 269 of 336 blocks, approximately 80%. Once in force, participants would reject blocks that failed to signal for the existing SegWit deployment. Coordination in July reduced the danger of a conflict around the August deadline. It did not mean SegWit itself had already locked in or activated in July. That deployment still followed its own BIP 9 mechanism. [4] [5] [9] [19]

Bitcoin Cash split off on 1 August 2017. Bitcoin ABC software supported larger blocks for this branch, then with a default limit of 8 MB. From the split onward, the networks had different rules and separate coins. Sharing the history before the split did not make later payments freely transferable between BTC and BCH. Bitcoin Cash was not SegWit2x, and Bitcoin ABC was not btc1. Confusing these names mixes up the August split with a different plan that was later suspended. They also differed in replay protection: how to prevent a transaction on one chain from being repeated on the other. For users, this technical issue had a practical consequence: working with one branch should not accidentally spend funds on the other. Shared keys were also unsafe to enter into an arbitrary tool promising new coins. [8] [15] [11]

SegWit entered the LOCKED_IN state at block 479 808 on 9 August 2017. The decision period was complete, with one waiting period remaining before enforcement of the new rules. SegWit became active at block 481 824 on 24 August. The two heights are 2 016 blocks apart. July’s BIP 91 coordination, August’s lock-in and activation itself were therefore separate events. The promised second stage of SegWit2x remained, scheduled for height 494 784. On 8 November, its organizers, led by Mike Belshe, announced its suspension. Their statement said they had not built enough agreement for a smooth upgrade. This did not remove the already active SegWit or make the separate Bitcoin Cash network disappear. It ended this particular attempt to turn company and miner support into an increase in Bitcoin’s limit. [9] [10] [12] [14] [16] [17]

The dispute showed that Bitcoin can change, but writing code, collecting company signatures and securing acceptance of rules are different tasks. It did not prove that developers have no influence, miners do not matter or every future decision will have the same outcome. Capacity, affordable verification and agreement among participants remain issues that cannot be resolved merely by renaming an upgrade. When reading a new proposal, first ask what it changes, which nodes would disagree afterward and how activation would work. Then distinguish the proposal, released software and rules actually in force. Contemporary BIPs and code document mechanisms; statements by the various sides document their positions. No individual participant’s statement is, by itself, an impartial account of the whole history. [1] [6] [11] [12]