BIP: 54 source
  Layer: Consensus (soft fork)
  Title: Consensus Cleanup
  Authors: Antoine Poinsot <mail@antoinep.com>
           Matt Corallo <bips@bluematt.me>
  Status: Draft
  Type: Specification
  Assigned: 2025-04-11
  License: CC0-1.0

This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without bip-0030 validation.

This proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin protocol. Bundling these fixes together amortizes the fixed cost of deploying a Bitcoin soft fork.

The timewarp bug permits a majority hashrate attacker to arbitrarily increase the block rate, allowing them to steal block subsidy from future miners and increase validation costs to nodes that have to deal with the increased average transaction rate. By strategically setting the block timestamp, the timewarp bug lets miners bring down the difficulty to its minimum within 38 days of starting the attack. The existence of this bug not only significantly empowers a 51% attacker, but also makes it notably harder to reason about miners' incentives. It could indeed be in the interest of short-sighted miners as well as short-sighted users to exploit this vulnerability in a small enough proportion to increase the block rate without fatally hurting the network, as the effectively increased block space would — all other things being equal — bring fee rates down for users.

Specially crafted blocks may be expensive to process, with validation times ranging from a few minutes up to more than an hour on lower-end devices. Long block validation times are a nuisance to users, increasing the cost to independently fully validate the consensus rules. In addition they can be used by miners to attack their competition, creating perverse incentives, centralization pressures and leading to reduced network security.

In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it possible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not part of a block, by pretending a 64-byte block transaction is actually an inner node¹. Invalidating 64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or any other user of Merkle proofs, to rely on one of the available workarounds² or even to know one is necessary in the first place.

Since bip-0034 activation, explicit bip-0030 validation is not necessary until block height 1,983,702³. Mandating new coinbase transactions be different from the early bip-0034 violations makes it possible to get rid of bip-0030 validation forever. Besides its unnecessary cost, another downside of bip-0030 validation is that it cannot be performed by Utreexo clients. Finally, leveraging the coinbase transaction's nLockTime field allows applications to recover the block height corresponding to a coinbase transaction without having to parse Script.

For all blocks after activation the following new rules apply.

Given a block at height N:

• if N % 2016 is equal to 0, the timestamp of the block must be set to a value higher than or equal to the value of the timestamp of block at height N-1 minus 7200 (T_N ≥ T_N−1 − 7200);
• if N % 2016 is equal to 2015, the timestamp of the block must be set to a value higher than or equal to the value of the timestamp of the block at height N-2015 (T_N ≥ T_N−2015).

A limit is set on the number of signature operations present in the scripts used to validate a transaction. It applies to all transactions in the block except the coinbase transaction⁴. For each input in the transaction, count the number of CHECKSIG and CHECKMULTISIG in the input scriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total summed over all transaction inputs is strictly higher than 2500, the transaction is invalid. The accounting is the same as for bip-0016, evaluating the scriptSig, scriptPubKey, and P2SH redeemScript separately:

1. CHECKSIG and CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated.
2. CHECKMULTISIG and CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operations, whether or not they are evaluated.
3. All other CHECKMULTISIG and CHECKMULTISIGVERIFY are counted as 20 signature operations, whether or not they are evaluated.

Transactions whose witness-stripped serialized size is exactly 64 bytes are invalid.

The coinbase transaction's nLockTime field must be set to the height of the block minus 1⁵ and its nSequence field must not be equal to 0xffffffff.

The restrictions on the timestamp of the first and last blocks of a difficulty adjustment period fix the timewarp and Murch–Zawy vulnerabilities⁶. The latter poses mostly theoretical concerns but is extremely low risk to fix: the duration of an adjustment period has never been, and should never be, negative. The former is fixed by preventing the timestamp of the first block of a difficulty period from being lower than the previous block's, with a two-hour grace period. A previous proposal to fix the timewarp attack used a ten-minute grace period instead, and this approach has been adopted for testnet4. Out of an abundance of caution and because it only trivially worsens the block rate increase under attack, a two-hour grace period is used here⁷.

Disabling some Script operations and functionalities was previously proposed to reduce the worst case block validation time but was met with resistance due to confiscation concerns⁸. A delicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even if merely theoretical, and bounding the costs one could impose on all other users of the system. To that end, limiting potentially executed signature operations targets the exact harmful behaviour while preserving maximal flexibility in Script usage. Such a limit reduces the worst case block validation time by a factor of 40 and drastically increases the preparation cost of an attack, making it uneconomical for a miner⁹. The maximum of 2500 was chosen as the tightest value that did not make any non-pathological standard transaction invalid¹⁰.

64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that burns them. They have also been non-standard since 2019 and never been used since 2016. Several alternatives to invalidating them were previously proposed. Some believe the improvements for users of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid witness-stripped transaction sizes. Others have suggested instead committing to the Merkle tree depth in the header's version field¹¹, which would make one workaround for a known vulnerability easier to deploy. The authors believe it is preferable to address the root cause by invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to rely on any workaround or even know one is necessary in the first place. See this post for an attempt at summarizing the arguments for both sides of this debate.

Several blocks prior to bip-0034 activation contain a coinbase transaction whose scriptSig contains a valid bip-0034 commitment to a future block height. This offers an opportunity to duplicate these coinbase transactions in the future¹² and for this reason bip-0030 validation will need to be re-activated from block 1,983,702. A simple way to prevent this is to mandate that future coinbase transactions vary from coinbase transactions before bip-0034 activation. There are multiple ways of achieving this, but setting and enforcing the timelock for the coinbase transaction makes it so all coinbase transactions past Consensus Cleanup activation could not have been valid before this height and therefore cannot be a duplicate¹³. This simplifies both reasoning and client implementation, since the bip-0030 check can be skipped entirely past Consensus Cleanup activation, regardless of the bip-0034 activation status¹⁴.

This proposal only tightens the block validation rules: there is no block that is valid under the rules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence these changes are backward-compatible with non-upgraded node software. That said, the authors strongly encourage node operators to upgrade in order to fully validate all consensus rules.

Bitcoin Core version 29.0 and later will not generate a block template that violates the timestamp restrictions introduced in this BIP. Although it would be extremely unlikely due to the grace period used in this proposal, miners should use the curtime or mintime field from the getblocktemplate result for their block's timestamp to make sure they always create blocks valid according to this proposal. Note this is not a new requirement: using a timestamp lower than the mintime field from the getblocktemplate result already leads to creating an invalid block.

Bitcoin Core version 30.0 and later will not generate a block template including a transaction that violates the signature operations limit introduced in this BIP.

Bitcoin Core version 0.16.1 and later will neither relay nor create block templates that include transactions whose witness-stripped serialized size is exactly 64 bytes.

The coinbase transaction is usually crafted by mining pool software. To the best of the authors' knowledge, there does not exist an open source reference broadly in use today for such software. We encourage mining pools to update their software to craft coinbase transactions that are forward-compatible with the changes proposed in this BIP.

An implementation of BIP54 for Bitcoin Core is available here.

Documented test vectors are available here for all mitigations introduced in this BIP.

This document builds upon an earlier proposal by Matt Corallo.

The authors would like to thank everyone involved in researching the most appropriate mitigation for each of these bugs. We would like to thank in particular Anthony Towns and Sjors Provoost for their direct contributions to this proposal, as well as @0xb10c and Brian Groll for providing the authors with data to analyze the proposed mitigations. Thanks to Chris Stewart for digging up historical violations to the new transaction size rule, which are partially reused in this BIP's test vectors.

This document is licensed under the Creative Commons CC0 1.0 Universal license.