BIP 101 Larger Bitcoin Blocks Explained: The Closed Growth Schedule

This guide explains BIP 101 Increase maximum block size in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The proposed growth curve

The schedule began at 8,000,000 bytes and doubled every 63,072,000 seconds, ignoring leap years. Limits between milestones grew linearly with timestamp until the 2036 cap. Exact integer arithmetic and timestamp selection would have been consensus-critical; two nodes rounding differently could disagree on a boundary block.

Deployment signalling

The proposal described miner-version signalling and a 75 per cent threshold intended to give miners, merchants and validating users time to upgrade. Signalling expressed software readiness under the plan, not automatic consent by every user. Activation of a larger block would still expose any fixed-limit node.

Why this was a hard fork

The first valid block above one megabyte under BIP 101 would be rejected by old fully validating nodes. Those nodes could remain on a lower-work or separately mined chain. Wallets and services needed explicit chain selection, deposit pauses and replay analysis rather than assuming the most visible tip was universally valid.

Technology-growth assumption

The doubling interval was justified by long-run improvements in bandwidth, storage and CPU. Such trends are uneven across countries and operators and may not continue indefinitely. A fixed exponential schedule shifts governance from later decisions into an earlier forecast, while the cost is borne by every future validating node.

Mining and propagation risk

Larger blocks take longer to transmit, reconstruct and validate, which can increase stale-block risk and favour well-connected miners. Compact relay can reduce bytes when mempools overlap but cannot eliminate full validation or worst-case data. Capacity evaluation must include uplink, memory, CPU, storage, reindex and initial sync.

UTXO and fee questions

The BIP did not directly constrain UTXO-set growth, and more transaction capacity can affect storage and fee-market dynamics. Block bytes, sigops, transaction shape and state growth are different resource dimensions. Raising one ceiling does not prove the node can safely handle every adversarial block beneath it.

Safe historical simulation

Implement the schedule on a private chain, test exact doubling boundaries and produce a block accepted by BIP 101 nodes but rejected by fixed-limit nodes. Measure propagation and validation under worst-case transaction shapes. Keep binaries, ports and datadirs entirely separate from production mining infrastructure.

Conclusion

BIP 101 encoded a predictable capacity forecast but required a hard fork and broad adoption that did not occur. It remains a useful scaling case study, not an active block-size rule for Bitcoin mainnet.