Great Consensus Cleanup

The Great Consensus Cleanup is a proposed soft fork that would fix four long-standing weaknesses in Bitcoin's consensus rules: the timewarp attack on difficulty adjustment, the worst-case validation cost of legacy signature operations, the ambiguity of 64-byte transactions in the Merkle tree, and the possibility of duplicate coinbase transactions that would require a return to BIP 30 validation. It is specified as BIP 54, "Consensus Cleanup", by Antoine Poinsot and Matt Corallo. The BIP has the status Complete and is not part of the mainnet consensus rules.

History

Matt Corallo proposed the original Great Consensus Cleanup in 2019. On 24 March 2024 Antoine Poinsot revived the work on Delving Bitcoin, measuring how slow a specially crafted block could be to validate, restating the incentive problem created by the timewarp vulnerability, and proposing a fix that would make BIP 30 validation unnecessary after block 1,983,702. The BIP number 54 was assigned on 11 April 2025.

Each of the four changes only restricts blocks that are valid today. The fixes are bundled into a single proposal to spread the fixed cost of deploying a Bitcoin soft fork across all of them. The proposal adds no new Script features.

Proposed rules

The following rules would apply to every block after activation.

Timewarp

Given a block at height N:

• if N modulo 2016 equals 0, the block's timestamp must be greater than or equal to the timestamp of block N−1 minus 7200 seconds;
• if N modulo 2016 equals 2015, the block's timestamp must be greater than or equal to the timestamp of block N−2015.

The first rule closes the timewarp attack, by which a majority of hash rate could lower the difficulty to its minimum within 38 days and steal block subsidy from future miners. The second rule closes the related Murch–Zawy vulnerability by preventing a difficulty period from having a negative duration. An earlier proposal used a ten-minute grace period, which was adopted for Testnet4; BIP 54 uses a two-hour grace period as a more cautious bound that only slightly increases the block rate an attacker could achieve. The existing median-time-past rule continues to apply.

Legacy signature operations

A non-coinbase transaction is invalid if the signature operations in its scriptSigs, the scriptPubKeys of the outputs it spends and any P2SH redeemScripts total more than 2500. Signature operations are counted as in BIP 16, whether or not they are executed: CHECKSIG and CHECKSIGVERIFY count as one, CHECKMULTISIG and CHECKMULTISIGVERIFY immediately preceded by OP_1 to OP_16 count as one to sixteen, and any other CHECKMULTISIG or CHECKMULTISIGVERIFY counts as twenty.

Specially crafted blocks can take several minutes to validate on high-end hardware and up to a few hours on low-end devices. The limit reduces the worst-case validation time by a factor of about 40 and makes such an attack uneconomical for a miner. The value 2500 is the tightest limit that leaves every non-pathological standard transaction valid. No opcode is disabled.

64-byte transactions

A transaction whose witness-stripped serialized size is exactly 64 bytes is invalid. When a block's Merkle root is computed, 64 bytes of data can be read either as a leaf or as an inner node made of two 32-byte hashes, which allows an SPV verifier to be shown an inclusion proof for a transaction that is not in the block. A 64-byte transaction can only have an output that anyone can spend or one that burns the funds, and none has been used on mainnet since 2016. Making them invalid removes the ambiguity for Merkle proofs of every other transaction, so light clients no longer need a workaround.

Coinbase uniqueness

The coinbase transaction's nLockTime must equal the block height minus 1, and its nSequence must not be 0xffffffff. Combined with the existing locktime rules, this guarantees that a new coinbase transaction cannot be identical to one that was valid in an earlier block, including the early coinbases that did not follow BIP 34. Nodes can therefore skip BIP 30 duplicate-transaction checks entirely after activation. Without the change, explicit BIP 30 validation would have to resume at block 1,983,702. Software can also read the block height from nLockTime without parsing the coinbase script.

Backward compatibility

Every block that is valid under BIP 54 is also valid under the current consensus rules, so the change is backward compatible with nodes that do not upgrade. Once a majority of hash rate enforces the new rules, miners that do not follow them would produce invalid blocks.

Implementation and deployment

Bitcoin Core pull request 35793 implements the BIP 54 rules without activating them on mainnet. BIP 54 does not specify a deployment mechanism, and no activation parameters or version bit have been assigned.

Recent Bitcoin Core releases already avoid producing blocks that would break the proposed rules. Bitcoin Core 29.0 and later do not generate block templates that violate the timestamp limits, and Bitcoin Core 30.0 and later do not include transactions that exceed the signature-operation limit. Since version 0.16.1, Bitcoin Core has neither relayed transactions whose witness-stripped size is exactly 64 bytes nor included them in block templates. Coinbase transactions are usually built by mining pool software rather than by Bitcoin Core, and the BIP asks mining pools to update their software so that their coinbases already set nLockTime and nSequence as the new rule requires.

See also

• Softfork
• Testnet4
• Taproot
• NLockTime
• Merkle tree

External links

• BIP 54: Consensus Cleanup
• Bitcoin Core PR 35793
• Great Consensus Cleanup Revival on Delving Bitcoin
• 2019 Great Consensus Cleanup draft by Matt Corallo