The Blocksize Wars

Scaling Bitcoin

Hi Plebs,

The debate over increasing Bitcoin's block size limit has been one of the most contentious and long-running controversies in Bitcoin’s history. At the heart of the issue was a fundamental trade-off between scalability and decentralisation.

Bitcoin's block size was originally limited to 1MB by Satoshi Nakamoto in 2010. This limit was largely forgotten until 2013, when it became the effective cap on the number of transactions that could be processed in each block. As Bitcoin adoption grew and transaction volume increased, the 1MB limit began to cause congestion on the network, leading to longer confirmation times and higher fees.

Supporters of increasing the block size argued that larger blocks would allow more transactions to be processed, improving Bitcoin's scalability and making it more useful as a payment system. They pointed to the fact that off-chain solutions like the Lightning Network were not yet ready to handle the load. Proponents included companies like BitPay, Blockchain.info, and Coinbase.

On the other side, opponents warned that increasing the block size would damage Bitcoin's decentralisation. Larger blocks would require more resources to download and store, making it more expensive to run a full node. This, they argued, would lead to fewer full nodes being operated, concentrating power in the hands of larger, better-resourced entities. Critics contended that Bitcoin's value proposition as a decentralised, trustless system would be undermined.

The debate saw the emergence of several different proposals to increase the block size:

BIP 100: Would have allowed miners to vote on the block size limit, with a range of 1MB to 32MB.

Bitcoin XT: Proposed an increase to 8MB, followed by doubling every two years.

BIP 102: Suggested a one-time increase to 2MB.

BIP 103: Called for a 17.7% annual increase until 2063.

Bitcoin Classic: Aimed for an immediate increase to 2MB, followed by a dynamic limit.

The key sticking point was whether these increases should be implemented via a "hard fork" - a backward-incompatible change that would split the network. Hard forks are risky, as they require near-universal adoption to prevent the creation of a new, competing cryptocurrency. This made many in the community hesitant to pursue a hard fork solution.

The debate grew increasingly heated, with some companies and individuals taking firm stances on either side. Entities like Magnr, Armory, and BitPay supported larger blocks, while Bitcoinpaygate, Bitrated, and GreenAddress opposed them.

Ultimately, the issue was resolved through the activation of Segregated Witness (SegWit) in 2017. SegWit increased the effective block size limit without requiring a hard fork, by separating transaction witness data from the main block. This allowed for a more gradual increase in transaction throughput, while preserving Bitcoin's decentralised nature.

The block size debate highlighted the challenges of governing a decentralised, open-source project like Bitcoin. It demonstrated the need for a careful, consensus-driven approach to making protocol changes, in order to maintain the network's security and integrity. The resolution of the block size issue, through the deployment of SegWit, has been seen as a testament to the resilience and adaptability of the Bitcoin ecosystem.

Cheers, and onwards with Bitcoin

Previous
Previous

Understanding Hard Forks

Next
Next

High vs Low Time Preference