The Blocksize Wars: How Bitcoin Chose Small Blocks and Won
In the summer of 2017, Bitcoin split in two on a Tuesday. On August 1, a group of miners and developers broke away and created a new chain with larger blocks, taking the name Bitcoin Cash. The original network did not blink. It kept producing blocks every ten minutes, and its node operators kept validating the same rules they had validated the day before. The fight that led to that day, known as the blocksize wars, lasted roughly two years and is the most important political event in Bitcoin's history. It was a fight over a single constant in the code: one megabyte.
Where the 1 MB limit came from
Early Bitcoin had no block size cap in the original release. Satoshi Nakamoto added a 1 MB limit in 2010, widely understood as an anti-spam measure at a time when the network was tiny and a single abusive miner could have bloated the chain cheaply. For years nobody cared, because blocks were nowhere near full. Then adoption grew. By 2015, blocks were regularly approaching the cap, transactions were queuing in the mempool, and a theoretical debate became a practical one.
The two camps
The case for bigger blocks was intuitive. If demand exceeds capacity, raise the capacity. Gavin Andresen, who had inherited lead maintainer duties from Satoshi, and Mike Hearn pushed for increases, first through Bitcoin XT in August 2015 and later Bitcoin Classic in early 2016. Their argument: Bitcoin should compete with payment networks like Visa, and cheap on-chain transactions are the product.
The case against was about who gets to verify. Every full node downloads and checks every block. Bigger blocks mean more bandwidth, more storage, and a longer initial sync, which prices ordinary people out of running a node. If only data centers can validate the chain, then the rules are whatever data centers say they are. Developers like Pieter Wuille, Greg Maxwell, and Luke Dashjr argued that the limit protects the one property that makes Bitcoin different from a bank: anyone can check the work. Their proposed path was to scale in layers, keeping the base chain lean and moving small payments to the Lightning Network.
Segregated Witness and the compromise attempts
The small-block camp's main technical answer was Segregated Witness, or SegWit. It moved signature data into a separate structure, fixed a long-standing transaction malleability bug that Lightning needed solved, and replaced the raw 1 MB limit with a 4,000,000 weight unit limit. In practice that allowed blocks of roughly 1.5 to 2 MB of data while remaining a soft fork, meaning old nodes would still accept the new blocks.
Compromises came and went. The Hong Kong roundtable in February 2016 produced a promise of SegWit plus a later hard fork increase, and it fell apart. In May 2017, a group of businesses and miners signed the New York Agreement, a plan called SegWit2x that bundled SegWit with a 2 MB hard fork. Many users saw this as a boardroom deal to rewrite Bitcoin's rules without asking the people who run the software.
The moment users took control
Miners had been sitting on SegWit for months, and the deadlock looked permanent. Then users escalated. A proposal called BIP148, the user-activated soft fork, said that on August 1, 2017, nodes enforcing it would reject any block that did not signal SegWit support. It was a credible threat that economic nodes, the exchanges, wallets, and individuals who actually accept bitcoin as payment, could force the issue without miner permission. Miners moved first. SegWit locked in during August 2017, and activated later that month.
The hard-fork camp's response was the August 1 split, with Bitcoin Cash forking off around block 478,558. The SegWit2x hard fork, meanwhile, was cancelled in November 2017 after it became clear it lacked broad support from the people who run nodes. The lesson stuck: miners produce blocks, but node operators decide which blocks count.
What it taught the network
The blocksize wars settled something that the whitepaper left open. Bitcoin's rules are not whatever a majority of hash power wants this quarter. They are whatever the economic majority of full nodes will enforce, and changing them requires near-unanimous consent. That makes Bitcoin deeply conservative by design. It is why proposals since then, from Taproot to everything in the pipeline, move slowly and ship as soft forks. It is also why the monetary policy, the 21 million cap, has never been seriously threatened. A network that survived a two-year fight over a few megabytes is not going to let anyone change the supply.
What you can do with this
- Run a node. The whole argument came down to nodes. A node on a spare machine is a vote for the rules you want. Our guide on running a Bitcoin node covers the setup.
- Read the primary sources. The mailing list threads and BIPs from 2015 to 2017 are public. Reading them is the fastest education in how Bitcoin governance really works.
- Be skeptical of urgency. Every contentious fork pitch arrives with a deadline and a promise of something better. Bitcoin's track record rewards the people who waited.
- Use layers. Small on-chain footprint, big off-chain activity. Try a Lightning payment and see why the small-block path was a design choice, not a limitation.
If you have read this far, you already know why the culture around Bitcoin is stubborn about the details. BitCloset makes heavyweight apparel for people who chose the small blocks, the full nodes, and the slow, boring rules. Browse the full collection, priced in sats.