Great Consensus Cleanup

Bitcoin's consensus rules carry a few known defects that nobody has fixed, because fixing them means a soft fork and soft forks are expensive to organize. The Great Consensus Cleanup is the idea of paying that cost once for several fixes together. Matt Corallo posted the first version to the bitcoin-dev list on March 6, 2019, with a draft BIP and a Bitcoin Core pull request. It never got a number. The script restrictions it proposed, disabling OP_CODESEPARATOR in legacy scripts, limiting scriptSigs to pushes and rejecting non-standard sighash bytes, were meant to cap how long a hostile block can take to validate, but they would also have invalidated some pre-signed transactions that could not be signed again, and that objection stuck. The pull request was closed in November 2019.

Antoine Poinsot reopened the question on Delving Bitcoin in March 2024 with measurements: how bad each bug is, how much each fix buys, and whether five more years of experience suggested better ones. The BIP that came out of it was assigned number 54 in April 2025, with Poinsot and Corallo as authors, and its text was marked complete in May 2026. It has four rules.

Time warp. The first block of each 2,016-block difficulty window must be stamped no earlier than two hours before the previous block, and the last block of a window no earlier than its first. The first rule closes the time warp attack. The second forbids a window from measuring a negative length, which closes a variant Zawy and Murch described during testnet4 review in 2024, with alternating future and past stamps on the last blocks of windows. Corallo had proposed a ten-minute grace, which testnet4 adopted in BIP-94; BIP-54 went to two hours after testnet4 showed pool software producing blocks that broke the shorter one, at a cost the BIP puts at about two seconds per block under attack.

Worst-case validation time. Legacy (pre-SegWit) scripts can be arranged so that a block takes minutes to validate on a fast machine and over an hour on a Raspberry Pi. Poinsot built one and kept the recipe among protocol developers. Rather than disable opcodes, BIP-54 counts the CHECKSIG and CHECKMULTISIG operations in each input's scriptSig, in the output script it spends and in any P2SH redeem script, whether or not a branch runs, and invalidates a transaction whose inputs total more than 2,500. The limit is the tightest value that no non-pathological standard transaction reaches, and the BIP says it cuts the worst case by a factor of 40.

64-byte transactions. A transaction that serializes to exactly 64 bytes without witness data is the same length as two hashes side by side, so it can be read as an inner node of the block's Merkle tree as well as a leaf. That lets an attacker fake an inclusion proof for a light client, at the cost of a large brute-force search, and the same ambiguity once tricked Bitcoin Core 0.13.0 through 0.13.2 into caching the wrong verdict for a block. Bitcoin Core has not relayed such transactions since 0.16.1, and none has been mined since 2016. BIP-54 makes them invalid.

Duplicate coinbases. Two early blocks, 91,842 and 91,880, repeated the coinbase of an earlier block byte for byte, and BIP-30 added a check that no transaction may reuse a txid whose outputs are still unspent. BIP-34 put the block height in the coinbase, which rules out a repeat until block 1,983,702, where a pre-BIP-34 coinbase happens to encode that height. BIP-54 requires every coinbase to set nLockTime to the block height minus one and nSequence to anything but 0xffffffff, so the time lock itself guarantees the transaction could not have been valid in an earlier block. Nodes can then drop the BIP-30 lookup for good, which also matters for designs like Utreexo that keep no full UTXO set to look things up in.

Every rule narrows what counts as a valid block, so nodes that never upgrade stay on the same chain. Miners are already most of the way there. Bitcoin Core has refused to build a template that violates the timestamp rules since version 29.0 and the signature-operation limit since 30.0, and has not relayed 64-byte transactions since 0.16.1. Activation is the part nobody has scheduled. The reference implementation, Bitcoin Core pull request #35793, carries the rules without a mainnet activation, and as of October 2026 the chain parameters hold no activation for it.