BIP 107 Dynamic Block Size Limit Explained

This guide explains BIP 107 Dynamic limit on the 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 fixed runway

Phase one scheduled two-megabyte blocks for 2016 and 2017, four megabytes for 2018 and 2019, then six megabytes in 2020. The runway was intended to relieve pressure while propagation, connectivity and layer-two systems improved. It was still a forecast embedded in consensus and required old validating nodes to upgrade.

The dynamic phase

From 2020, the design checked the preceding 4,032 blocks, about four weeks. If at least 3,025 were at least sixty per cent of the current maximum, the cap rose by ten per cent. It never decreased. Exact inequalities, block window selection and integer rounding would have been consensus-critical.

Why sustained fullness was chosen

The threshold represented roughly three quarters of the window and sought to distinguish sustained demand from ordinary variance. Sixty per cent left distance from full capacity, while a higher threshold risked congestion before adjustment. Historical variance cannot guarantee that future demand or adversarial behaviour follows the same distribution.

Manipulation and free relay

Miners and users can create transaction volume, including low-fee traffic. The proposal raised limitfreerelay proportionally and argued that sustained filling would be costly. Net cost, self-paid fees, censorship and pool coordination still complicate the signal. Block fullness is observable but is not a neutral vote from all Bitcoin users.

Hard-fork activation

The suggested deployment followed BIP 101-style version signalling: 750 of 1,000 blocks followed by a two-week grace period. Signalling could indicate miner readiness but could not make oversized blocks valid to unupgraded nodes. Services required explicit branch, replay, deposit and rollback procedures.

Mining and node resources

Larger blocks affect propagation, validation, memory, storage, reindex and stale-block risk differently. A ten per cent cap change does not mean every resource rises by exactly ten per cent. Testing needs adversarial transaction and signature shapes, compact-relay misses and primary-to-failover consistency.

Historical reproduction

Implement the schedule on a private chain and test the 3,024 and 3,025 qualifying-block boundary, consecutive windows and every rounding step. Construct the first block above the old limit and prove that a standard historical node rejects it. Measure the cost of manufacturing qualifying fullness and document all assumptions.

Conclusion

BIP 107 combined a fixed runway with demand-triggered increases, but its utilisation signal, irreversible growth and hard-fork boundary remained governance and security choices. It should be studied, not enabled on current Bitcoin nodes.