BIP 106 Dynamic Bitcoin Block Size Cap Explained

BIP 106 Dynamic Bitcoin Block Size Cap: This guide explains BIP 106 Dynamically Controlled Bitcoin Block Size Max Cap in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

Two alternative algorithms

Proposal one looked only at block fullness over a difficulty period. Proposal two compared block sizes and transaction fees across two overlapping windows. They were alternatives rather than one combined rule, so an implementation or historical analysis must identify which formula it means before claiming compatible results.

Utilisation-only thresholds

In the first algorithm, if more than half of the first 2,000 blocks were over ninety per cent full, the cap doubled. If more than ninety per cent were below half full, it halved. Otherwise it stayed unchanged. Boundary comparison, selected-block count and integer units would all affect consensus.

Fee-aware ratio proposal

The second algorithm summed 4,016 blocks split into two 2,008-block windows, with an eight-block overlap described in the source. Growth required average use above half the cap plus rising fees and sizes; contraction required the inverse. The next cap followed the ratio between recent aggregate sizes.

Can demand signals be manufactured

Miners influence both transaction selection and their own block size, and can pay fees to themselves while bearing only part of the apparent cost. Users can also generate traffic. A deterministic formula is reproducible, but its inputs can remain strategic. Manipulation analysis must follow net economic cost, not headline fee totals.

Halving the cap safely

A falling cap could make transactions and templates that previously fitted suddenly too large. Mempool state, fee estimation and pool construction would need to adjust at the exact boundary. A sharp halving also changes throughput even when the observed low use was temporary or caused by censorship or network interruption.

Hard-fork deployment

Any later block above the old one-megabyte rule would split unupgraded validators from proposal nodes. The BIP suggested activation at a future difficulty boundary if consensus existed, but did not make adoption automatic. Economic nodes and users, not just miners, determine which rule set they accept.

Reproduce before interpreting

Build both algorithms independently and feed them synthetic periods at exactly fifty, ninety and one-hundred per cent thresholds. Vary fees separately from sizes and include self-paid fees. Confirm the eight-block overlap, rounding and cap units, then show the first block rejected by a standard historical node.

Conclusion

BIP 106 tried to make capacity follow measured demand, but measurement, incentives and boundary arithmetic became consensus rules of their own. Its closed algorithms belong in isolated research rather than current Bitcoin operations.