Three 2015 block size proposals exposed a missing process

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

Three competing proposals, no process to choose between them

In mid-2015, three formal proposals to raise Bitcoin's one-megabyte block size limit existed side by side. BIP101, dated 22 June 2015 and authored by Gavin Andresen, proposed replacing the fixed limit with a cap that doubles every two years, starting at 8 megabytes in January 2016 and reaching roughly 8 gigabytes by 2036, activated by miners signalling a specific block version. A day later, BIP102, from Jeff Garzik, proposed a single one-off increase to 2 megabytes, requiring a flag-day timestamp plus 95 percent miner signalling. The following month, BIP103, from Pieter Wuille, proposed a formula tying the limit to elapsed time from January 2017, growing roughly 17.7 percent a year to track historical bandwidth trends. Three credentialed developers, three incompatible answers, published within five weeks of each other.

What each document actually specifies

The mechanism differences matter as much as the numbers. BIP101 is a hard fork: nodes that do not adopt it will reject blocks larger than one megabyte, so a supermajority of hashpower can drag the network onto an incompatible chain if enough nodes fail to upgrade in time. BIP102 shares that hard-fork character but proposes a fixed target rather than a growth curve. BIP103 is the most gradual of the three, expressed as a maximum of 175 stepped increases running through 2063, calculated from the median time of preceding blocks rather than a single flag day, which the document frames as a way to avoid a hard cutoff tied to any one calendar date.

The boundary: no document settles who decides

None of these three BIPs is, on its own text, evidence that a block size increase happened; none reached deployment in the form written. What they establish jointly is procedural: Bitcoin in 2015 had a mechanism for nodes to signal support for a change through block version bits, but no agreed authority for choosing between mutually exclusive proposals once developers, users and miners preferred different ones. A reader who later encounters an account of a 'block size war' should treat the competing technical proposals and the political dispute over which should win as related but separate facts; these three documents describe only the former.

Questions to carry forward

• When multiple valid technical proposals conflict, what decides which activates: developer consensus, miner signalling, node adoption, or some combination?
• Does a hard-fork proposal's stated activation threshold protect users who do not upgrade, or does it depend on them upgrading anyway?
• What later record, if any, shows how or whether the disagreement between these three proposals was formally resolved?

Read together, the three BIPs are a primary record of a genuine technical disagreement conducted through formal proposals rather than informal argument. That they could not, by themselves, produce an outcome is itself the finding worth keeping.