BIP 109 Two-Megabyte Block Proposal Explained

BIP 109 Two-Megabyte Block Proposal: This guide explains BIP 109 Two million byte size limit with sigop and sighash limits in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.

Two-million-byte ceiling

The canonical serialised block limit would double from 1,000,000 to 2,000,000 bytes. That was a hard-fork expansion because an older validator would reject an otherwise valid oversized block. The apparently simple constant also altered propagation, storage, validation and stale-block economics.

Accurate sigop counting

The 20,000 limit would count signature checks actually executed rather than conservative static estimates. Coinbase scriptSig and unexecuted branches were excluded; CHECKMULTISIG cost depended on how far verification searched. Identical implementations needed matching script execution and invalid-encoding treatment.

Signature-hashing limit

A separate 1.3-billion-byte ceiling bounded data hashed while computing transaction signatures. This addressed quadratic-style CPU exhaustion in large transactions. Block bytes, executed signatures and hashed bytes measured different resources, so passing one limit did not imply a cheap block.

Activation and expiry

Miners signalled bit 0x10000000. A triggering block required at least 750 of its preceding 1,000 blocks to signal, followed by 28 days before new limits applied. Failure to trigger before 1 January 2018 withdrew the proposal. Signal arithmetic and timestamps were consensus-sensitive.

Old-node partition

The first block above the old size limit or accepted under changed sigop rules could separate legacy nodes. SPV wallets might continue following headers but would not prove that every economic validator agreed. Exchanges, pools and merchants needed branch-specific controls beyond counting signalling blocks.

Mining benchmark

Test worst-case script and signature-hashing shapes, compact relay with unequal mempools, validation on failover hardware and reindex. Accurate counting can admit scripts previously charged conservatively, so template builders and validators must share the same implementation and activation state.

Historical fork simulation

On a disposable network, reproduce the 749 and 750 signalling boundary, grace-period timestamp and expiry. Build blocks at every byte, sigop and sighash edge and show old-node rejection. Preserve exact binaries and fixtures, because current Bitcoin software does not implement BIP 109 as active consensus.

Conclusion

BIP 109 paired a capacity increase with explicit CPU limits, but it still required a hard fork and coordinated rule adoption that did not occur. Its constants are historical test material, not present Bitcoin limits.