BIP 105 Block Size Retargeting Explained

This guide explains BIP 105 Consensus based block size retargeting algorithm in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

The problem the proposal targeted

Coordinating repeated hard forks was seen as too slow for sudden demand, while a predetermined growth schedule could overestimate future hardware and weaken fee pressure. Free miner voting could also be sold or used strategically. BIP 105 attempted to make upward preference costly while retaining a protocol-level upper boundary.

Coinbase vote encoding

After the BIP 34 block-height push, a miner would push a little-endian preferred size in bytes into the coinbase scriptSig. A miner could request an increase or decrease of at most ten per cent from the current limit, or vote for no change. Every validating implementation needed identical parsing and range rules.

Proof-of-work penalty for increases

A block voting upward had to meet a proportionally harder target than the normal network difficulty. A block failing the vote-adjusted target would be invalid even if it met ordinary difficulty. The extra work was intended to make an increase costly, but it also created unusual validation, incentive and variance effects.

Median every 2,016 blocks

At each difficulty interval, the next block-size limit would be the median of the preceding 2,016 votes. Median selection resists some extremes but does not prove that the result reflects users or node operators. Exact treatment of malformed, missing and out-of-range votes would be consensus-critical.

Asymmetric voting incentives

A decrease required no extra proof of work, whereas an increase sacrificed expected block-finding probability. Larger pools might tolerate the penalty differently from small miners. Pools, hashers and validating users would therefore face incentives not captured by a simple preference ballot, including template policy and out-of-band compensation.

Hard-fork compatibility boundary

When the computed limit exceeded one megabyte, a block valid under the proposal could be rejected by an old node. Dynamic adjustment did not remove the hard fork. Services needed explicit chain selection, deposit controls, replay analysis and tested rollback at the first divergent block.

Historical simulation

On an isolated chain, encode minimum, unchanged and maximum votes, vary the vote-adjusted target and calculate several median windows independently. Include malformed pushes, ties and boundary targets. Show rejection by an unmodified fixed-limit node and quantify the effective revenue cost for differently sized miners.

Conclusion

BIP 105 combined miner preference with an explicit proof-of-work price, but it remained a hard-fork governance proposal with complex incentives and consensus-sensitive arithmetic. It is useful history, not production configuration.