BIP-54's Great Consensus Cleanup: Four Consensus Bugs Fixed and Nothing New?

ARCHIVED SOURCE url: https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork/ canonical: https://bitcoinops.org/en/topics/consensus-cleanup-soft-fork captured_utc: 2026-11-06T03:35:30.733Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- Consensus cleanup soft fork is a proposal to address several issues in Bitcoin’s consensus rules that date back to the original version of Bitcoin released in 2009. After a prior draft in 2019 was deferred, renewed efforts since 2023 substantiated into a concrete proposal, BIP54: Consensus Cleanup. The soft fork proposal advocates for fixing the following four issues. ● Time warp bug : an off-by-one error in the difficulty adjustment algorithm permits a majority hashrate attacker to arbitrarily increase block cadence. This is mitigated by limiting the permitted timestamps for the first block in difficulty periods and requiring that an entire difficulty period has a non-negative duration. ● Slow-to-validate blocks : attackers may use uncommon script patterns to compose blocks that are prohibitively expensive to process. These forms of malicious transactions are prevented by introducing limits on signature operations that curb this malicious use but far exceed organic uses. ● Merkle tree weakness : the construction of the merkle tree on a block’s transactions treats transactions with witness-stripped sizes of 64 bytes indistinguishably from inner nodes. Forbidding such transactions prevents two ways of misrepresenting the content of a valid block. ● Duplicate transaction vector : Some early coinbase transactions exhibit patterns that would allow them to be replayed in future blocks. Requiring that the locktime of coinbase transactions is set to a specific value based on the block height enforces that future coinbase transactions are unique without needing to enforce BIP30 checks for those blocks. CVE-2017-12842: fake SPV proofs using 64-byte transactions

ARCHIVED SOURCE url: https://github.com/bitcoin/bips/blob/master/bip-0054.md canonical: https://github.com/bitcoin/bips/blob/master/bip-0054.md captured_utc: 2026-11-06T03:35:15.011Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- BIP: 54 Layer: Consensus (soft fork) Title: Consensus Cleanup Authors: Antoine Poinsot <[email protected]> Matt Corallo <[email protected]> Status: Complete Type: Specification Assigned: 2025-04-11 License: CC0-1.0 Abstract 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 makes it possible for a majority-hashrate attacker to arbitrarily lower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an attacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides empowering a 51% attacker, the presence of this bug makes it harder to reason about miners' incentives. Accelerating the block rate allows an attacker to steal block subsidy from future miners and increases available block space. It may be in the interest of short-sighted users and miners to exploit this vulnerability to materially increase the block rate without fatally hurting the network. Specially crafted blocks may be expensive to process, taking up to several minutes to validate even on high-end devices, and up to a few hours 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 1 . 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 2 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 3 . Resuming bip-0030 validation would unnecessarily increase block validation overhead and preclude alternative full node designs (such as bip-0182 Utreexo). Enforcing that new coinbase transactions are different from the early bip-0034 violations makes it possible to get rid of bip-0030 validation forever. For all blocks after activation the following new rules apply. 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 4 . For each input in the transaction, count the number of signature operations from CHECKSIG ( VERIFY ) and CHECKMULTISIG ( VERIFY ) 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: 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 5 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 6 . 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 7 . 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 8 . 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 9 . The maximum of 2500 was chosen as the tightest value that did not make any non-pathological standard transaction invalid 10 . 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 (discussion here ). Others have suggested instead committing to the Merkle tree depth in the header's version field 11 , or even invalidating Merkle tree nodes that correspond to a valid serialisation for a Bitcoin transaction 12 . These options make some of the available workarounds 2 easier to deploy. The authors believe it is preferable to address the root cause by invalidating 64-byte transactions. This fixes the vulnerability for users relying on Merkle proofs of non-64-byte transactions, without requiring a workaround. The nLockTime field of transactions is a natural place to store a block height and is currently unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from early bip-0034 violations also allows applications to recover the block height without having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained: the same coinbase transaction cannot have been valid in a previous block 13 . 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 14 . One person raised the concern that the nLockTime field would be an ideal extranonce for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others replied that the same benefits could be achieved by using a dummy output instead, should that ever become necessary. The authors believe the benefits of using nLockTime to differentiate coinbase transactions outweigh the theoretical cost of making it unavailable for extranonce rolling by ASIC controllers. 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. Conversely, pretending that the inner nodes on one level of the tree are the actual block transactions is another source of complexity for full node implementations, which previously resulted in consensus bugs. For instance, Bitcoin Core versions between 0.13.0 and 0.13.2 implemented caching that made it vulnerable to this attack. See this writeup by Suhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but the issue is largely orthogonal to this proposal: it is fundamentally about caching validation status for malleable blocks. ↩ The authors are aware of three workarounds for SPV verifiers. The first is to request a Merkle proof for the coinbase transaction in addition to the transaction of interest, to infer the depth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a valid serialisation of a Bitcoin transaction. More details about these are available here . A third workaround is to change the Merkle proof structure by requiring inner nodes to be provided as the single-SHA256 of their preimage, instead of the double-SHA256. See here for a full description. ↩ ↩ 2 Block 1,983,702 is the earliest future block which could contain a duplicate coinbase transaction while still respecting bip-0034 . See this post for a list of all such future blocks. ↩ Technically this limit cannot apply to a coinbase transaction as the size of its sole input's scriptSig is limited. ↩ The locktime validation, which is also performed for coinbase transactions, enforces that the nLockTime value is the last block at which a transaction is invalid, not the first one at which it is valid. ↩ The timewarp attack is described here and the Murch–Zawy attack here . ↩ The testnet4 difficulty exception pushed blocks' timestamps in the future when abused, revealing how some broken pool software may produce blocks that don't respect a 10 minutes grace period. Some raised concerns similarly broken software might be used on mainnet. Using a grace period of 2 hours instead of 10 minutes only reduces the expected block interval time under attack by ~2.2 seconds. See this post for more. ↩ The argument is about someone having a timelocked presigned transaction using some of those features in its output script. The transaction cannot be mined before activation. Such outputs would not be covered by an amnesty for old UTxOs. See for instance here and here for discussions on this topic. ↩ It is important to reduce the worst case block validation time as well as the ratio of validation time imposed over preparation cost. The former is to limit the damages an externally motivated attacker can do. The latter is to disincentivize miners slowing down their competition by mining expensive blocks. See this thread for more. ↩ A non-pathological transaction would have a public key per signature operation and at least one signature per input. Per standardness a single P2SH input may not have more than 15 signature operations. Even by using 1-of-15 CHECKMULTISIG s a transaction would bump against the maximum standard transaction size before running into the newly introduced limit. To run against the newly introduced limit but not the transaction size a transaction would need to spend P2SH inputs with a redeem script similar to CHECKSIG DROP CHECKSIG DROP ... . This type of redeem script serves no purpose beyond increasing its validation cost, which is exactly what this proposal aims to mitigate. ↩ By Sergio Demian Lerner in a blog post . ↩ Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list) . ↩ Technically it could be argued a duplicate could in principle always be possible before block 31,001 when nLockTime enforcement was originally soft-forked . But treating coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent for any implementation which enforces nLockTime from the genesis block, which is the behaviour notably of Bitcoin Core but also of all other implementations the authors are aware of. ↩ For instance Bitcoin Core only disables bip-0030 validation for a specific chain where bip-0034 violations have been manually inspected (see here ). Without the guarantee given by enforcing the timelock on coinbase transactions, this would have to be perpetuated for the Consensus Cleanup. ↩

ARCHIVED SOURCE url: https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki canonical: https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki captured_utc: 2026-11-06T03:35:14.464Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- BIP: XXXX Layer: Consensus (soft fork) Title: The Great Consensus Cleanup Author: Matt Corallo Status: Draft Type: Standards Track Created: 2019-01-28 License: PD This BIP defines a set of consensus changes which reduce the complexity of Bitcoin implementations and improve worst-case validation times, fixing a number of long-standing vulnerabilities. BIP 143 significantly improved certain aspects of Bitcoin's consensus rules, key to this being changes to the format of the data which is hashed and signed in CHECKSIG operations during script execution. However, several improvements were left for later forks to avoid bloating the original activation with unrelated changes. This BIP seeks to make some of these changes as well as a few other simplifications. Specifically, this BIP proposes the following changes: Upon activation, the following rules will be enforced on all new blocks: This BIP will be deployed by "version bits" BIP9 with the name "cleanups" and using bit (0-indexed) 3. For Bitcoin mainnet, the BIP9 starttime will be midnight August 1st, 2019 UTC (Epoch timestamp 1564617600) and BIP9 timeout will be midnight August 1st, 2020 UTC (Epoch timestamp 1596240000). For Bitcoin testnet, the BIP9 starttime will be midnight June 1st, 2019 UTC (Epoch timestamp 1559347200) and BIP9 timeout will be midnight June 1st, 2020 UTC (Epoch timestamp 1590969600). [1] The difficulty adjustment algorithm in Bitcoin multiplies the previous difficulty by (2016 / time taken to mine the last 2015 blocks). Intuitively[2], this implies the actual Inter-Block-Time (IBT) target is 2016/2015*600, or about 600.3 seconds. However, the expected value of the inverse of an Erlang distribution (which the above is effectively sampling from) is actually 1/(N-1), not 1/N. Thus, the above expression actually targets an IBT of 2016/2014*600, or about 600.6 seconds, ie E(2016*600/X) = 1 where X~ErlangDistribution(k=2015, λ=1/IBT) when IBT is 2016/2014*600. This is equivalent to 600*E(2016*600/X) where X~ErlangDistribution(k=2015, λ=1/600). In the case of a miner deliberately reducing timestamps by 600 seconds on the difficulty-retargeting block, we are effectively changing the difficulty multiplier to (2016 / (time taken to mine the last 2016 blocks + 600)), or 600*E(2016*600/(X + 600)) where X~Erlang Distribution(k=2016, λ=1/600), which is effectively targeting an inter-block time of ~599.9999 seconds. [2] See https://twitter.com/pwuille/status/1098288749098795008 for most peoples' intuition. For more info see Pieter's writeup at https://gist.github.com/sipa/1a70884abe6d0a7cddc340c99f741a41 [3] While no official stratum specification exists, the btc.com pool server (one of the most popular pool servers today) rejects shares with timestamps more than 600 seconds in the future at https://github.com/btccom/btcpool/blob/e7c536834fd6785af7d7d68ff29111ed81209cdf/src/bitcoin/StratumServerBitcoin.cc#L384 . While there are few resources describing hardware operation today, timestamp rolling can be observed on the chain (in some rare cases) as block timestamps go backwards when a miner rolled one block nTime forward and the next does not, but only incredibly rarely more than 600 seconds. [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html [5] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180609/9f4f5b1f/attachment-0001.pdf [6] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-February/016697.html Thanks (in alphabetical order) to Suhas Daftuar, James Hilliard, Johnson Lau, Steve Lee, Greg Maxwell, John Newberry, and Pieter Wuille for their helpful feedback at various stages as well as the entire Bitcoin Protocol Development Community.

ARCHIVED SOURCE url: https://github.com/bitcoin/bitcoin/pull/15482 canonical: https://github.com/bitcoin/bitcoin/pull/15482 captured_utc: 2026-11-06T03:35:13.410Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- Based on #15481 . BIP available at https://github.com/TheBlueMatt/bips/blob/cleanup-softfork/bip-XXXX.mediawiki (I'll post it on the mailing list later tonight, hopefully). There was an error while loading. Please reload this page . Reviewers, this pull request conflicts with the following ones: If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. Increases timeout for travis after b6f0db6 (apparently) didn't increase it enough. Restrict timestamp when mining a diff-adjustment block to prev-600 &hellip; 1d72dd8 This prepares us for a potential future timewarp-fixing softfork by ensuring that we always refuse to mine blocks which refuse to exploit timewarp, no matter the behavior of other miners. Note that we allow timestamp to go backwards by 600 seconds on the difficulty-adjustment blocks to avoid bricking any existing hardware which relies on the ability to roll nTime by up to 600 seconds. Note that it is possible that the eventual softfork to fix timewarp has a looser resetriction than the 600 seconds enforced here, however it seems unlikely we will apply a tighter one, and its fine if we restrict things further on the mining end than in consensus. Ensure the script-fail reason is correct on mandatory flags &hellip; 570eae7 Previously, if we fail both due to a STANDARD_NOT_MANDATORY_SCRIPT_VERIFY_FLAGS and a MANDATORY_SCRIPT_VERIFY_FLAGS, we would potentially return the non-mandatory error as the reason for mandatory-script-verify-flag-failed. This ensures we always return the correct error. Avoid creating <= 64-byte transactions in most functional tests. f9b3940 Implement BIPXXX's new softfork rules (The Great Consensus Cleanup) &hellip; 1f63030 Some notes: * Three tests use non-push opcodes in scriptSigs, so those have the fork explicitly disabled. * The 64-byte transaction check is executed in a new ContextualBlockPreCheck which must be run before CheckBlock (at least in the final checking before writing the block to disk). This function is a bit awkward but is seemingly the simplest way to implement the new check, with the caveat that, because the new function is called before CheckBlock, it can never return a non-CorruptionPossible error state. TheBlueMatt force-pushed the 2019-02-great-consensus-cleanup branch from 3de8267 to 1f63030 Compare February 26, 2019 19:06 practicalswift commented Copy link Copy Markdown Contributor --> --> jnewbery mentioned this pull request Mar 3, 2019 Newsletters: add #36 (2019-03-05) bitcoinops/bitcoinops.github.io#113 Merged Sjors mentioned this pull request Mar 4, 2019 Soft fork notifications jonathanbier/forkmonitor#19 Closed DrahtBot commented Copy link Copy Markdown Contributor --> --> DrahtBot added the Needs rebase label Mar 5, 2019 maaku commented edited Uh oh! There was an error while loading. Please reload this page . I'm a bit surprised that the possibility of using forward blocks to achieve future scaling is not mentioned in the BIP or PR, since the absolute removal of the time-warp attack vector closes off the possibility of using the bug for forward- and backwards-compatible soft-fork scaling in the future, as I covered in my talk at Scaling Bitcoin last year. While developing the idea of forward blocks I sent a vulnerability report email to some of the senior Bitcoin Core developers. In it I outlayed some analysis of the attack vectors, and a suggested solution which both prevents the sort of attacks which could be devastating to the network, while still allowing uses of the time-warp "feature" to achieve on-chain scaling when it becomes necessary at some point in the future. I'll quote that part of the email here: ...It turns out this is to the advantage of bitcoin users as the time warp is an integral part of how we can make a block size increase and/or PoW change without a hard fork, and thereby allow such proposals be decided on their own merits rather than as a yea or nay decision on hard forks generally. ...This is an issue that has been known about for some time and persists as unfixed because, as I understand it, the likelihood of attack was low and likelihood of coordinated user response high. And since ideas like Forward Blocks require the time-warp bug to achieve forwards-compatible scaling of settlement capacity, I would think it short sighted to advocate for "fixing" the bug now. However in discussing forward blocks with another developer, I happened upon a solution that would allow for the worst scenarios to be avoided while not blocking off the later deployment of forward blocks: If the current block timestamp is more than 4 hours beyond the median time of the past 11 blocks, then the difficulty adjustment errors if the adjustment would exceed a smaller limiting factor than the normal +/- 4x. Specifically I recommend ensuring that the block timestamp is within the range [start + 600*2015 - 4800, start + 600*2015 + 4800]. 4800 = 80 * 60 = 1 hour 20 minutes. This would allow decreases in the inter-block time of no more than 12.6% the first year of purposeful adjustments, and is easy to implement. (Potentially the lower limit could be removed as it would be nice for the difficulty to be able to quickly reset, but asymmetric adjustments have been a source of error in the past.) This would prevent ... [censored bug disclosure] ... while still allowing a rate of growth for forward blocks or other proposals to that is conservative slow enough as to not cause catastrophic failure. Requiring the block timestamp to be 4 hours ahead of the median time past ensures this rule is very unlikely to be engaged during normal operation of a healthy network, for which normal [unconstrained] difficulty adjustments can still occur. This approach additionally has the advantage of being less disruptive than what is implemented in this PR. No rule changes are engaged at all until such time as the adjustment block's timestamp is 4 hours ahead of median time past, so there is no risk to un-upgraded miners outside of a time-warp regime because a block more than 2 hours in the future is considered invalid. I think this modified rule would make it safe to switch to BIP8 instead of BIP9 for deployment. Can you split the soft-fork rules into separate commits, away from the activation logic? E.g. it's hard to spot the OP_CODESEPERATOR change if you're not familiar with #11423 that made it non-standard. Shameless review plug for #12134 , so we can test the interaction with older nodes. …SegWit ef72e9b doc: nChainTx needs to become a 64-bit earlier due to SegWit (Sjors Provoost) Pull request description: As of block 597,379 txcount is 460,596,047 (see `chainparams.cpp`), while `uint32` can handle up to 4,294,967,296. Pre segwit the [minimum transaction size]( https://en.bitcoin.it/wiki/Maximum_transaction_rate ) was 166 bytes, so the worst case number of transactions per block was ~6000. As the original source comment for `unsigned int nChainTx` says, that should last until the year 2030. With SegWit the smallest possible transaction is 60 bytes (potentially increased to 65 with a future soft fork, see #15482 ), without a witness: ``` 4 bytes version 1 byte input count 36 bytes outpoint 1 byte scriptSigLen (0x00) 0 bytes scriptSig 4 bytes sequence 1 byte output count 8 bytes value 1 byte scriptPubKeyLen 1 byte scriptPubKey (OP_TRUE) 4 bytes locktime ``` That puts the maximum number of transactions per block at 16,666 so we might have to deal with this as early as a block 827,450 in early 2024. Given that it's a memory-only thing and we want to allow users many years to upgrade, I would suggest fixing this in v0.20 and back-porting it. ACKs for top commit: practicalswift: re-ACK ef72e9b jarolrod: ACK ef72e9b theStack: ACK ef72e9b Tree-SHA512: d8509ba7641796cd82af156354ff3a12ff7ec0f7b11215edff6696e95f8ca0e3596f719f3492ac3acb4b0884ac4e5bddc76f107b656bc2ed95a8ef1b2b5d4f71 bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022 --> This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters to subscribe to this conversation on GitHub . Already have an account? Sign in . --> Uh oh! There was an error while loading. Please reload this page .

ARCHIVED SOURCE url: https://bitcoin.org/bip/54/ canonical: https://bitcoin.org/bip/54 captured_utc: 2026-11-06T03:35:12.252Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- 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 makes it possible for a majority-hashrate attacker to arbitrarily lower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an attacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides empowering a 51% attacker, the presence of this bug makes it harder to reason about miners' incentives. Accelerating the block rate allows an attacker to steal block subsidy from future miners and increases available block space. It may be in the interest of short-sighted users and miners to exploit this vulnerability to materially increase the block rate without fatally hurting the network. Specially crafted blocks may be expensive to process, taking up to several minutes to validate even on high-end devices, and up to a few hours 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 1 . 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 2 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 3 . Resuming bip-0030 validation would unnecessarily increase block validation overhead and preclude alternative full node designs (such as bip-0182 Utreexo). Enforcing that new coinbase transactions are different from the early bip-0034 violations makes it possible to get rid of bip-0030 validation forever. For all blocks after activation the following new rules apply. 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 4 . 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: 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 5 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 6 . 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 7 . 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 8 . 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 9 . The maximum of 2500 was chosen as the tightest value that did not make any non-pathological standard transaction invalid 10 . 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 (discussion here ). Others have suggested instead committing to the Merkle tree depth in the header's version field 11 , or even invalidating Merkle tree nodes that correspond to a valid serialisation for a Bitcoin transaction 12 . These options make some of the available workarounds 13 easier to deploy. The authors believe it is preferable to address the root cause by invalidating 64-byte transactions. This fixes the vulnerability for users relying on Merkle proofs of non-64-byte transactions, without requiring a workaround. The nLockTime field of transactions is a natural place to store a block height and is currently unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from early bip-0034 violations also allows applications to recover the block height without having to parse Script. Leveraging the existing timelock mechanism makes the check self-contained: the same coinbase transaction cannot have been valid in a previous block 14 . 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 15 . One person raised the concern that the nLockTime field would be an ideal extranonce for ASIC controllers if such controllers ever became a bottleneck in mining operations. Others replied that the same benefits could be achieved by using a dummy output instead, should that ever become necessary. The authors believe the benefits of using nLockTime to differentiate coinbase transactions outweigh the theoretical cost of making it unavailable for extranonce rolling by ASIC controllers. 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. Conversely, pretending that the inner nodes on one level of the tree are the actual block transactions is another source of complexity for full node implementations, which previously resulted in consensus bugs. For instance, Bitcoin Core versions between 0.13.0 and 0.13.2 implemented caching that made it vulnerable to this attack. See this writeup by Suhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but the issue is largely orthogonal to this proposal: it is fundamentally about caching validation status for malleable blocks. ↩︎ The authors are aware of three workarounds for SPV verifiers. The first is to request a Merkle proof for the coinbase transaction in addition to the transaction of interest, to infer the depth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a valid serialisation of a Bitcoin transaction. More details about these are available here . A third workaround is to change the Merkle proof structure by requiring inner nodes to be provided as the single-SHA256 of their preimage, instead of the double-SHA256. See here for a full description. ↩︎ Block 1,983,702 is the earliest future block which could contain a duplicate coinbase transaction while still respecting bip-0034 . See this post for a list of all such future blocks. ↩︎ Technically this limit cannot apply to a coinbase transaction as the size of its sole input's scriptSig is limited. ↩︎ The locktime validation, which is also performed for coinbase transactions, enforces that the nLockTime value is the last block at which a transaction is invalid, not the first one at which it is valid. ↩︎ The timewarp attack is described here and the Murch–Zawy attack here . ↩︎ The testnet4 difficulty exception pushed blocks' timestamps in the future when abused, revealing how some broken pool software may produce blocks that don't respect a 10 minutes grace period. Some raised concerns similarly broken software might be used on mainnet. Using a grace period of 2 hours instead of 10 minutes only reduces the expected block interval time under attack by ~2.2 seconds. See this post for more. ↩︎ The argument is about someone having a timelocked presigned transaction using some of those features in its output script. The transaction cannot be mined before activation. Such outputs would not be covered by an amnesty for old UTxOs. See for instance here and here for discussions on this topic. ↩︎ It is important to reduce the worst case block validation time as well as the ratio of validation time imposed over preparation cost. The former is to limit the damages an externally motivated attacker can do. The latter is to disincentivize miners slowing down their competition by mining expensive blocks. See this thread for more. ↩︎ A non-pathological transaction would have a public key per signature operation and at least one signature per input. Per standardness a single P2SH input may not have more than 15 signature operations. Even by using 1-of-15 CHECKMULTISIG s a transaction would bump against the maximum standard transaction size before running into the newly introduced limit. To run against the newly introduced limit but not the transaction size a transaction would need to spend P2SH inputs with a redeem script similar to CHECKSIG DROP CHECKSIG DROP ... . This type of redeem script serves no purpose beyond increasing its validation cost, which is exactly what this proposal aims to mitigate. ↩︎ By Sergio Demian Lerner in a blog post . ↩︎ Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list) . ↩︎ The authors are aware of three workarounds for SPV verifiers. The first is to request a Merkle proof for the coinbase transaction in addition to the transaction of interest, to infer the depth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a valid serialisation of a Bitcoin transaction. More details about these are available here . A third workaround is to change the Merkle proof structure by requiring inner nodes to be provided as the single-SHA256 of their preimage, instead of the double-SHA256. See here for a full description. ↩︎ Technically it could be argued a duplicate could in principle always be possible before block 31,001 when nLockTime enforcement was originally soft-forked . But treating coinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent for any implementation which enforces nLockTime from the genesis block, which is the behaviour notably of Bitcoin Core but also of all other implementations the authors are aware of. ↩︎ For instance Bitcoin Core only disables bip-0030 validation for a specific chain where bip-0034 violations have been manually inspected (see here ). Without the guarantee given by enforcing the timelock on coinbase transactions, this would have to be perpetuated for the Consensus Cleanup. ↩︎

ARCHIVED SOURCE url: https://github.com/bitcoin/bitcoin/pull/35793 canonical: https://github.com/bitcoin/bitcoin/pull/35793 captured_utc: 2026-11-06T03:35:11.994Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- This patchset is based on the code that was previously reviewed ( 1 , 2 ) and tested (for instance here ) on Bitcoin Inquisition. The tests and documentation have since been improved, but the consensus-critical commits have been carried over with only minor differences (the only behavioural one being the addition of the stripped-size check to PreChecks ). Roughly 95% of the added lines are tests or test data. The format, contents, and reproduction procedure for the BIP 54 test vectors are documented here . The bip54_tests unit test module exercises each mitigation extensively in isolation. The feature_bip54.py functional test verifies all of them end-to-end after and prior to activation. For the timestamp rules, it simulates timewarp and Murch–Zawy attacks, demonstrating the new timestamp rules prevent these exploits. A fuzz harness for the sigop accounting logic is also included, which can be seeded from the BIP test vectors (implemented here ). There was an error while loading. Please reload this page . See the guideline and AI policy for information on the review process. If your review is incorrectly listed, please copy-paste <!--meta-tag:bot-skip--> into the comment that the bot should ignore. Reviewers, this pull request conflicts with the following ones: If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python): Possible places where comparison-specific test macros should replace generic comparisons: Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example: Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch. A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test. Leave a comment here, if you need help tracking down a confusing failure. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . the asymmetry between OP_1 CHECKMULTISIG and (empty) CHECKMULTISIG sounds striking as the vbyte cost of a single CHECKMULTISIG is going to be 1 vbyte and the fee cost of a OP_1 CHECKMULTISIG , so in any collaborative txn among multi parties, one can force the tx to reach the new 2500 limit at a vbyte cost inferior rather than putting a OP_1 CHECKMULTISIG coming with a higher absolute vbyte cost, whatever the feerate. curious if there is any rational somewhere in all the design notes, that's explaining that choice for the asymmetry in the legacy signature accounting for CHECKMULTISIG There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Before #33050 a tx could have been executed twice, the first with standardness rule, the second with consensus check. An attacker could have done a marginal attack, where the tx would have had a huge OP_SHA256 element to hash and the minimal number of accounted for 20 OP_CHECKMULTISIG. Therefore the transaction would have failed a first time on the standard check and then a second time on the consensus check with a reduced liquidity cost for the attacker (due to the lower feerate surface). and there was easy way to optimize the attack. This one of the attack I did mention there even if never went to communicate it properly. I might have still have the python test vectors I played with at the time. Somehow the 20 OP_CHECKMULTISIG is a compact trick to render a tx invalid with the minimal of tx surface. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . I am not sure what you are trying to get at. Could your point be related to this previous one you raised on the list? There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . No it's something quite different. What I'm talking about in the present issue, it was relying on crafting small weight unit transaction to provoke the most of OP_SHA256 (it's less expensive than sigs, but it's still consuming some CPU cycles) during a validation, and therefore the smallest cost. Note, it was strictly before #33050 that I did the test. It's not only the worst-case in CPU time to consider it's for a minimal mempool min fee, what's the average satoshis liquidity must avails to consume useless CPU cycles. I'll find back my notes on this and come back to you. There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . I understand that the BIP mentions 2016/2015 because it describes mainnet's adjustment period. Since this PR applies the deployment only to regtest by default, could we adjust the BIP text, or add a note here to clarify that these values are derived from the network's adjustment period rather than fixed constants? There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . I think your comment applies to the difficulty adjustment period values used by the timewarp and Murch-Zawy mitigations, not that commit (which sets a largely inconsequential dummy BIP 9 deployment for regtest), correct? So i went and looked for a way to maybe clarify this for the code implementing those checks, but it's already pretty clear these values are derived from the network's adjustment period. Timewarp : // If the block is the first of a difficulty adjustment interval, check its timestamp against the previous // one to prevent timewarp attacks (see BIP 54). const int dai{ static_cast < int >(consensusParams. DifficultyAdjustmentInterval ())}; const bool is_first_block{nHeight % dai == 0 }; if (is_first_block) { Murch-Zawy : // Fix for the Murch-Zawy attack. See https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062 . // TL;DR: the duration of a retarget period must not be negative or the difficulty adjustment limit may be exploited to unduly // reduce difficulty similarly to the timewarp vulnerability. Along with the timewarp fix, this effectively makes retarget periods // monotonic (modulo the timewarp fix grace period). const bool is_last_block{nHeight % dai == dai - 1 }; if (is_last_block && DeploymentActiveAfter(pindexPrev, chainman, Consensus:: DEPLOYMENT_CONSENSUSCLEANUP )) { int first_height{nHeight - dai + 1 }; Happy to consider any improvement to the comments there. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . The code looks fine, was just wondering if we could update the BIP to make 2016 and 2015 variables, and in this PR draw attention to the fact that - strictly speaking - we're diverging from the BIP. There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . 64-byte transactions are also now treated as a consensus failure in PreChecks, like BIP54-sigops check failures. Note this only changes the RPC error, and not the disconnection behaviour in P2P since 266dd0e . qa: unit tests for BIP54 rule on 64-byte transactions (with JSON test… &hellip; 1f487ba … vectors) This adds tests exercising the bounds of the checks on the invalid transaction size, for various types of transactions (legacy, Segwit, bytes in input/output to get to 64 bytes) as well as sanity checking against some known historical violations. Thanks to Chris Stewart for digging up the historical violations to this rule. qa: end-to-end test all BIP54 mitigations &hellip; 7407f3c The previously introduced unit tests extensively test the specific implementation of each mitigation. This functional test complements them by end-to-end testing all mitigations. For the added timestamp constraints, it mimicks how they would get exploited (by implementing pseudo timewarp and Murch-Zawy attacks) and demonstrates those exploits are not possible anymore after BIP54 activates. doc: add a BIP 54 entry to bips.md 3f0f142 darosior force-pushed the bip54 branch from fa6b7a7 to 3f0f142 Compare October 22, 2026 20:05 instagibbs commented Copy link Copy Markdown Member Minor changes only, including hte Assert() move in CheckContextualBlock I checked the sigop count against btclib, a library I maintain, on the 39 published sigop vectors and on 27 cases of my own: the 2500/2501 bound across P2SH, bare multisig and CHECKMULTISIG in the scriptSig, oversized redeem scripts, and scriptSigs whose last item is not the redeem script. The PR and btclib agree on all of them. The size, timestamp and coinbase vectors also agree with a short checker I wrote from the BIP text. The unit suite, the touched functional tests and a 5-minute run of bip54_sigops pass. Nit: the txsize.json case "A 61-byte legacy transaction with a witness" is 60 bytes stripped and 64 with its witness, as the Assert s in bip54_txsize say. The BIP's txsize.json has the same comment. @ViniciusCestarii 's mutant can be caught on regtest. On a node started with -vbparams=consensuscleanup:0:3999999999 -acceptnonstdtxn=1 , the deployment is only started, and the PR rejects a 2501-sigop transaction in testmempoolaccept with bad-txns-legacy-sigops . Under the mutant it is accepted, while feature_bip54.py , mempool_sigoplimit.py and mempool_accept.py still pass. That check could go in feature_bip54.py . I can share it and my other scripts as a gist. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . This commit breaks existing getblocktemplate calls on Regtest. With gbt_optional_rule = false and ALWAYS_ACTIVE on Regtest, a getblocktemplate call now has to include "consensuscleanup" in the "rules" ( {"rules": ["segwit", "consensuscleanup"]} ). Otherwise the error "Support for 'consensuscleanup' rule requires explicit client support" is returned. This affects external mining software, Stratum proxies, and other projects' integration tests. In our tests this works as NORMAL_GBT_REQUEST_PARAMS is updated too. This is a behavior change that warrants mentioning in release notes. Making the rule optional ( gbt_optional_rule = true ) is another option for discussion. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Elsewhere (in ContextualCheckBlock ) the value bad-txns-size is used. I propose using the same value here as well, and dropping txn-size-64 , for consistency. Whether the error code should be 64-byte specific or not, is up for discussion. (I lean towards the more generic bad-txns-size , but I'm indifferent.) There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Order of checks: I believe any validity check should come before standardness checks. Otherwise a tx that fails both checks is reported as non-standard, instead of the stronger invalid. I propose moving the 64-byte invalid check before the IsStandardTx call before. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Nit: There is no assert here that indeed the tx is 64 bytes, I suggest adding one, like in submit_block_64byte above. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Minor: Isn't this 60 bytes, not 61? INVALID_TX_NONWITNESS_SIZE - 4 There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Nit: The 64 here could be replaced by INVALID_TX_NONWITNESS_SIZE now. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Unconditional consensus error at mempool check. 64-byte transactions are rejected from mempool with consensus error now, regardless of deployment (so on mainnet as well). This is inconsistent, as such transactions are considered consensus-valid at block checking. The status quo is rejecting 64-byte transactions with non-standardness error. Therefore the behavior is unchanged, only the error is changed from non-standard to invalid in this case. All this seems intended behavior. Nonetheless, I think it would make sense to explicitly mention this inconsistency in: The discarded alternative is to reject with consensus failure only if BIP54 is active, otherwise leave the non-standardness rejection. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . The 64-byte rule is tested on BIP54-active chain (RegTest) only, not on non-active chain. I recommend adding a test on mainnet, to verify non-activation on mainnet (at current heights). There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Minor optimization observation: a custom, IsSizeInvalid() method could perform faster than the generic compute-size-and-compare-to-64. However, the difference is minimal, especially compared to costly part of block validation. Nonetheless, a custom method would make the intent more explicit and leave room for further optimization. /* * Whether the witness-stripped serialized size of this transaction is exactly 64 bytes (BIP 54). */ bool IsSizeInvalid ( const CTransaction& tx) { // Each input takes at least 41 and each output at least 9 non-witness bytes, on top of // 10 bytes for the version, locktime and the input and output counts. if ( 10 + 41 * tx. vin . size () + 9 * tx. vout . size () > INVALID_TX_NONWITNESS_SIZE ) return false ; return :: GetSerializeSize ( TX_NO_WITNESS (tx)) == INVALID_TX_NONWITNESS_SIZE ; } --> --> ViniciusCestarii commented edited Uh oh! There was an error while loading. Please reload this page . I also published them at https://mutanthub.space/projects/bitcoin/bitcoin/pulls/35793 , where they can be discussed. @@ -2519,7 +2519,7 @@ bool Chainstate::ConnectBlock(const CBlock& block, BlockValidationState& state, std::optional<CCheckQueueControl<CScriptCheck>> control; if (auto& queue = m_chainman.GetCheckQueue(); queue.HasThreads() && fScriptChecks) control.emplace(queue); - const bool enforce_bip54{DeploymentActiveAt(*pindex, m_chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)}; + const bool enforce_bip54{DeploymentActiveAfter(pindex, m_chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)}; std::vector<int> prevheights; CAmount nFees = 0; int nInputs = 0; Timewarp skipped at activation block @@ -4115,7 +4115,7 @@ static bool ContextualCheckBlockHeader(const CBlockHeader& block, BlockValidatio if (consensusParams.enforce_BIP94) { static_assert(MAX_TIMEWARP_TESTNET4 <= MAX_TIMEWARP_BIP54); max_timewarp = MAX_TIMEWARP_TESTNET4; - } else if (DeploymentActiveAfter(pindexPrev, chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)) { + } else if (DeploymentActiveAt(*pindexPrev, chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)) { max_timewarp = MAX_TIMEWARP_BIP54; } if (max_timewarp && block.GetBlockTime() < pindexPrev->GetBlockTime() - *max_timewarp) { Coinbase locktime skipped at activation @@ -4197,7 +4197,7 @@ static bool ContextualCheckBlock(const CBlock& block, BlockValidationState& stat } // Make sure the coinbase transaction is timelocked to the block's height. - if (nHeight > 0 && DeploymentActiveAfter(pindexPrev, chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)) { + if (nHeight > 0 && DeploymentActiveAt(*pindexPrev, chainman, Consensus::DEPLOYMENT_CONSENSUSCLEANUP)) { if (block.vtx[0]->nLockTime != static_cast<uint32_t>(nHeight - 1)) { return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-cb-locktime", "block height mismatch in coinbase nLockTime"); } --> --> fametrano added a commit to btclib-org/btclib that referenced this pull request Oct 27, 2026 Check the BIP54 consensus rules, held to bip-0054's vectors ( closes #… &hellip; c4931ff …2799 ) ( #2830 ) One public function per BIP54 rule, each refusing with the reject reason bitcoin/bitcoin#35793 gives: - tx_context.assert_bip54_sig_ops: at most MAX_TX_LEGACY_SIGOPS legacy signature checks per transaction (bad-txns-legacy-sigops); - tx_context.assert_bip54_tx_size: no transaction of 64 bytes without witness (bad-txns-size); - header_context.assert_bip54_timestamps: the timewarp and Murch-Zawy bounds at a retarget boundary (time-timewarp-attack, time-negative-interval); - tx_context.assert_bip54_coinbase: the coinbase locked to the height before its block, its sequence not final (bad-cb-locktime, bad-cb-sequence). Each is an assert_* beside the rules of the same Core function: assert_coinbase_maturity and assert_coinbase_value in tx_context, assert_not_timewarp in header_context. Each applies its rule unconditionally, leaving activation to the caller, as tx_context leaves BIP68's. The sigop count is the one policy.are_inputs_standard already ran; both now call one private function in tx_context. MAX_TX_LEGACY_SIGOPS moves to tx.limits beside INVALID_TX_NONWITNESS_SIZE, and policy re-exports it, so no public name changes. MAX_TIMEWARP_BIP54 joins block.limits. The tests read bip-0054's sigops.json, txsize.json, coinbases.json and timestamps.json, pinned in tests/_data/README.md: txsize.json byte for byte, the other three without the blank line upstream ends them with. The README's list of files vendored since its last re-check also gains rust-bitcoin's huge_witness.bin, which it lacked. Each refusal's message stays a BTClibValueError for any value, a huge lock time included, as huge_int_message_test.py checks. Co-Authored-By: Claude Opus 5.5 <[email protected]> Signed-off-by: Ferdinando Ametrano <[email protected]> ViniciusCestarii reviewed Oct 28, 2026 View reviewed changes ViniciusCestarii left a comment Copy link Copy Markdown Contributor There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . assert_equal(len(block.vtx[0].serialize_without_witness()), 64) --> --> Comment thread test/functional/feature_bip54.py block = create_block ( tmpl = { "previousblockhash" : blocks [ - 1 ]. hash_hex , "height" : height , "curtime" : start_time + 4 * interval_expected_sec , ViniciusCestarii Oct 28, 2026 Copy link Copy Markdown Contributor There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page .

ARCHIVED SOURCE url: https://github.com/bitcoin-inquisition/bitcoin/pull/99 canonical: https://github.com/bitcoin-inquisition/bitcoin/pull/99 captured_utc: 2026-11-06T03:35:09.828Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- There was an error while loading. Please reload this page . Each of the 4 mitigations comes with its own unit test in a new src/test/bip54_tests.cpp module. The unit tests can be used to generate JSON test vectors for the BIP (opt-in). For those unit tests that require mainnet blocks, the JSON test vectors were generated separately and included in this PR as data files. Besides the unit test for each mitigation, this contains a fuzz harness for the sigop accounting logic as well as a functional test which goes over all mitigations in pseudo realistic situations (for instance, mimic a Timewarp attack and a Murch-Zawy attack to demonstrate the new timestamp restrictions would prevent that). The fuzz target for the sigop accounting logic was designed to make it possible to seed it from the BIP test vectors. This branch implements that. The chains of headers for the timestamp restrictions test vectors were generated using this unit test (note the premined headers to allow modifications without re-generating all headers from scratch). The small chains of blocks for the coinbase restrictions test vectors were generated using this unit test . There was an error while loading. Please reload this page . Reviewers, this pull request conflicts with the following ones: If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . Do we want to keep the CheckSigopsBIP54 check in standardness too? (I don't recall what we've done for others) There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . diff --git a/src/consensus/tx_verify.cpp b/src/consensus/tx_verify.cpp index cd5e3f6680f54..6cf134c772f63 100644 --- a/src/consensus/tx_verify.cpp +++ b/src/consensus/tx_verify.cpp @@ -161,6 +161,9 @@ int64_t GetTransactionSigOpCost(const CTransaction& tx, const CCoinsViewCache& i return nSigOps; } + /** + * Check the total number of non-witness sigops across the whole transaction, as per BIP54. + */ bool Consensus::CheckSigopsBIP54(const CTransaction& tx, const CCoinsViewCache& inputs) { Assert(!tx.IsCoinBase()); @@ -187,7 +190,7 @@ bool Consensus::CheckSigopsBIP54(const CTransaction& tx, const CCoinsViewCache& return true; } - bool Consensus::CheckTxInputs(const CTransaction& tx, TxValidationState& state, const CCoinsViewCache& inputs, int nSpendHeight, CAmount& txfee) + bool Consensus::CheckTxInputs(const CTransaction& tx, TxValidationState& state, const CCoinsViewCache& inputs, int nSpendHeight, CAmount& txfee, bool bip54_active) { // are the actual inputs available? if (!inputs.HaveInputs(tx)) { @@ -195,6 +198,10 @@ bool Consensus::CheckTxInputs(const CTransaction& tx, TxValidationState& state, strprintf("%s: inputs missing/spent", __func__)); } + if (bip54_active && !Consensus::CheckSigopsBIP54(tx, inputs)) { + return state.Invalid(TxValidationResult::TX_CONSENSUS, "bad-txns-legacy-sigops", "too many legacy sigops (BIP54)"); + } + CAmount nValueIn = 0; for (unsigned int i = 0; i < tx.vin.size(); ++i) { const COutPoint &prevout = tx.vin[i].prevout; diff --git a/src/consensus/tx_verify.h b/src/consensus/tx_verify.h index f387fed7fd6dd..af1eafca9f112 100644 --- a/src/consensus/tx_verify.h +++ b/src/consensus/tx_verify.h @@ -28,9 +28,10 @@ bool CheckSigopsBIP54(const CTransaction& tx, const CCoinsViewCache& inputs); * Check whether all inputs of this transaction are valid (no double spends and amounts) * This does not modify the UTXO set. This does not check scripts and sigs. * @param[out] txfee Set to the transaction fee if successful. + * @param[in] bip54_active Whether to perform the BIP54 sigops check. * Preconditions: tx.IsCoinBase() is false. */ - [[nodiscard]] bool CheckTxInputs(const CTransaction& tx, TxValidationState& state, const CCoinsViewCache& inputs, int nSpendHeight, CAmount& txfee); + [[nodiscard]] bool CheckTxInputs(const CTransaction& tx, TxValidationState& state, const CCoinsViewCache& inputs, int nSpendHeight, CAmount& txfee, bool bip54_active); } // namespace Consensus /** Auxiliary functions for transaction validation (ideally should not be exposed) */ diff --git a/src/policy/policy.cpp b/src/policy/policy.cpp index 35c9f9cddf2d2..8388bae043e68 100644 --- a/src/policy/policy.cpp +++ b/src/policy/policy.cpp @@ -190,10 +190,6 @@ bool AreInputsStandard(const CTransaction& tx, const CCoinsViewCache& mapInputs) return true; // Coinbases don't use vin normally } - if (!Consensus::CheckSigopsBIP54(tx, mapInputs)) { - return false; - } - for (unsigned int i = 0; i < tx.vin.size(); i++) { const CTxOut& prev = mapInputs.AccessCoin(tx.vin[i].prevout).out; diff --git a/src/test/fuzz/coins_view.cpp b/src/test/fuzz/coins_view.cpp index c435ed91ba793..4a37a315c0314 100644 --- a/src/test/fuzz/coins_view.cpp +++ b/src/test/fuzz/coins_view.cpp @@ -255,7 +255,8 @@ FUZZ_TARGET(coins_view, .init = initialize_coins_view) // It is not allowed to call CheckTxInputs if CheckTransaction failed return; } - if (Consensus::CheckTxInputs(transaction, state, coins_view_cache, fuzzed_data_provider.ConsumeIntegralInRange<int>(0, std::numeric_limits<int>::max()), tx_fee_out)) { + const bool bip54_active{fuzzed_data_provider.ConsumeBool()}; + if (Consensus::CheckTxInputs(transaction, state, coins_view_cache, fuzzed_data_provider.ConsumeIntegralInRange<int>(0, std::numeric_limits<int>::max()), tx_fee_out, bip54_active)) { assert(MoneyRange(tx_fee_out)); } }, diff --git a/src/test/transaction_tests.cpp b/src/test/transaction_tests.cpp index 5f4de9b141d16..f185bf23304ae 100644 --- a/src/test/transaction_tests.cpp +++ b/src/test/transaction_tests.cpp @@ -1021,6 +1021,9 @@ BOOST_AUTO_TEST_CASE(test_IsStandard) BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) { + TxValidationState state; + const int dummy_height{0}; + CAmount dummy_fee; CCoinsView coins_dummy; CCoinsViewCache coins(&coins_dummy); CKey key; @@ -1052,7 +1055,8 @@ BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) // 2490 sigops is below the limit. BOOST_CHECK_EQUAL(GetP2SHSigOpCount(CTransaction(tx_max_sigops), coins), 2490); - BOOST_CHECK(::AreInputsStandard(CTransaction(tx_max_sigops), coins)); + BOOST_CHECK(Consensus::CheckTxInputs(CTransaction(tx_max_sigops), state, coins, dummy_height, dummy_fee, /*bip54_active=*/true)); + BOOST_CHECK(state.IsValid()); // Adding one more input will bump this to 2505, hitting the limit. tx_create.vout.emplace_back(424242, max_sigops_p2sh); @@ -1064,7 +1068,9 @@ BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) AddCoins(coins, CTransaction(tx_create), 0, false); BOOST_CHECK_GT((p2sh_inputs_count + 1) * MAX_P2SH_SIGOPS, MAX_TX_LEGACY_SIGOPS); BOOST_CHECK_EQUAL(GetP2SHSigOpCount(CTransaction(tx_max_sigops), coins), 2505); - BOOST_CHECK(!::AreInputsStandard(CTransaction(tx_max_sigops), coins)); + BOOST_CHECK(!Consensus::CheckTxInputs(CTransaction(tx_max_sigops), state, coins, dummy_height, dummy_fee, /*bip54_active=*/true)); + BOOST_CHECK(state.IsInvalid()); + state = TxValidationState{}; // Now, check the limit can be reached with regular P2PK outputs too. Use a separate // preparation transaction, to demonstrate spending coins from a single tx is irrelevant. @@ -1083,7 +1089,8 @@ BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) // The transaction now contains exactly 2500 sigops, the check should pass. BOOST_CHECK_EQUAL(p2sh_inputs_count * MAX_P2SH_SIGOPS + p2pk_inputs_count * 1, MAX_TX_LEGACY_SIGOPS); - BOOST_CHECK(::AreInputsStandard(CTransaction(tx_max_sigops), coins)); + BOOST_CHECK(Consensus::CheckTxInputs(CTransaction(tx_max_sigops), state, coins, dummy_height, dummy_fee, /*bip54_active=*/true)); + BOOST_CHECK(state.IsValid()); // Now, add some Segwit inputs. We add one for each defined Segwit output type. The limit // is exclusively on non-witness sigops and therefore those should not be counted. @@ -1099,7 +1106,8 @@ BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) // The transaction now still contains exactly 2500 sigops, the check should pass. AddCoins(coins, CTransaction(tx_create_segwit), 0, false); - BOOST_REQUIRE(::AreInputsStandard(CTransaction(tx_max_sigops), coins)); + BOOST_CHECK(Consensus::CheckTxInputs(CTransaction(tx_max_sigops), state, coins, dummy_height, dummy_fee, /*bip54_active=*/true)); + BOOST_CHECK(state.IsValid()); // Add one more P2PK input. We'll reach the limit. tx_create_p2pk.vout.emplace_back(212121, p2pk_script); @@ -1111,7 +1119,8 @@ BOOST_AUTO_TEST_CASE(max_standard_legacy_sigops) } AddCoins(coins, CTransaction(tx_create_p2pk), 0, false); BOOST_CHECK_GT(p2sh_inputs_count * MAX_P2SH_SIGOPS + p2pk_inputs_count * 1, MAX_TX_LEGACY_SIGOPS); - BOOST_CHECK(!::AreInputsStandard(CTransaction(tx_max_sigops), coins)); + BOOST_CHECK(!Consensus::CheckTxInputs(CTransaction(tx_max_sigops), state, coins, dummy_height, dummy_fee, /*bip54_active=*/true)); + BOOST_CHECK(state.IsInvalid()); } BOOST_AUTO_TEST_SUITE_END() diff --git a/src/txmempool.cpp b/src/txmempool.cpp index 3a5a3fb306d38..4a3dfb35d02ab 100644 --- a/src/txmempool.cpp +++ b/src/txmempool.cpp @@ -777,7 +777,7 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei TxValidationState dummy_state; // Not used. CheckTxInputs() should always pass CAmount txfee = 0; assert(!tx.IsCoinBase()); - assert(Consensus::CheckTxInputs(tx, dummy_state, mempoolDuplicate, spendheight, txfee)); + assert(Consensus::CheckTxInputs(tx, dummy_state, mempoolDuplicate, spendheight, txfee, /*bip54_active=*/true)); for (const auto& input: tx.vin) mempoolDuplicate.SpendCoin(input.prevout); AddCoins(mempoolDuplicate, tx, std::numeric_limits<int>::max()); } diff --git a/src/validation.cpp b/src/validation.cpp index c1b71643cffd3..e242d78a06be2 100644 --- a/src/validation.cpp +++ b/src/validation.cpp @@ -872,7 +872,7 @@ bool MemPoolAccept::PreChecks(ATMPArgs& args, Workspace& ws) } // The mempool holds txs for the next block, so pass height+1 to CheckTxInputs - if (!Consensus::CheckTxInputs(tx, state, m_view, m_active_chainstate.m_chain.Height() + 1, ws.m_base_fees)) { + if (!Consensus::CheckTxInputs(tx, state, m_view, m_active_chainstate.m_chain.Height() + 1, ws.m_base_fees, /*bip54_active=*/true)) { return false; // state filled in by CheckTxInputs } @@ -2642,7 +2642,7 @@ bool Chainstate::ConnectBlock(const CBlock& block, BlockValidationState& state, { CAmount txfee = 0; TxValidationState tx_state; - if (!Consensus::CheckTxInputs(tx, tx_state, view, pindex->nHeight, txfee)) { + if (!Consensus::CheckTxInputs(tx, tx_state, view, pindex->nHeight, txfee, /*bip54_active=*/check_bip54)) { // Any transaction validation failure in ConnectBlock is a block consensus failure state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, tx_state.GetRejectReason(), @@ -2656,12 +2656,6 @@ bool Chainstate::ConnectBlock(const CBlock& block, BlockValidationState& state, break; } - if (check_bip54 && !Consensus::CheckSigopsBIP54(tx, view)) { - state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-txns-legacy-sigops", - "contains a transaction with too many legacy sigops (BIP54)"); - break; - } - // Check that transaction is BIP68 final // BIP68 lock checks (as opposed to nLockTime checks) must // be in ConnectBlock because they require the UTXO set diff --git a/test/functional/mempool_sigoplimit.py b/test/functional/mempool_sigoplimit.py index afd8cf968b6a8..17ec53edfea90 100755 --- a/test/functional/mempool_sigoplimit.py +++ b/test/functional/mempool_sigoplimit.py @@ -183,7 +183,7 @@ def create_bare_multisig_tx(utxo_to_spend=None): assert_greater_than(2000, tx_parent.get_weight() + tx_child.get_weight()) def test_legacy_sigops_stdness(self): - self.log.info("Test a transaction with too many legacy sigops in its inputs is non-standard.") + self.log.info("Test a transaction with too many legacy sigops in its inputs is invalid.") # Restart with the default settings self.restart_node(0) @@ -204,18 +204,18 @@ def test_legacy_sigops_stdness(self): outpoints.append(COutPoint(txid, res["sent_vout"])) self.generate(self.nodes[0], 1) - # Spending all these outputs at once accounts for 2505 legacy sigops and is non-standard. + # Spending all these outputs at once accounts for 2505 legacy sigops and is invalid. nonstd_tx = CTransaction() nonstd_tx.vin = [CTxIn(op, CScript([b"", packed_redeem_script])) for op in outpoints] nonstd_tx.vout = [CTxOut(0, CScript([OP_RETURN, b""]))] - assert_raises_rpc_error(-26, "bad-txns-nonstandard-inputs", self.nodes[0].sendrawtransaction, nonstd_tx.serialize().hex()) + assert_raises_rpc_error(-26, "bad-txns-legacy-sigops", self.nodes[0].sendrawtransaction, nonstd_tx.serialize().hex()) - # Spending one less accounts for 2490 legacy sigops and is standard. + # Spending one less accounts for 2490 legacy sigops and is valid and standard. std_tx = deepcopy(nonstd_tx) std_tx.vin.pop() self.nodes[0].sendrawtransaction(std_tx.serialize().hex()) - # The non-std transaction can also not be mined now it's been made a consensus rule. + # The invalid transaction also cannot appear in a block. assert_raises_rpc_error(-25, "bad-txns-legacy-sigops", self.generateblock, self.nodes[0], "raw(42)", [nonstd_tx.serialize().hex()]) def run_test(self): --> --> instagibbs Dec 17, 2025 Copy link Copy Markdown There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . I think this PR is well organised (starting at ---). Each consensus change is first prepared, done in a minimal commit, and then followed by new tests. I'll study the test changes in more detail later. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . Will review more the fixes at the conceptual level and the breadth / depth of their respective test coverage. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . The other consensus commit changes for the 19d159ed3757e871f7cc525f2623117d8ffe3498 push (compared to my previous review) look fine. There was an error while loading. Please reload this page . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . If we think it's important to only return a consensus error after 54 becomes active, then we should go back to duplicating the check instead of having it as part of CheckTxInputs (see this thread for why it was changed #99 (comment) ). There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . It's not clear to me that it's worth it. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . For now i'm switching the stripped size error to be a consensus one as well, but i'm curious to hear what you think. There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . There was an error while loading. Please reload this page . This encapsulates the soft fork configuration logic as set by the `-testactivationheight` (for buried deployments) and `-vbparams` (for version bits deployments) options which for the moment are regtest-only, in order to make them available on other networks as well in the next commit. Can be reviewed using git's --color-moved option. darosior force-pushed the 2509_inquisition_consensus_cleanup branch from 19d159e to f24256f Compare December 29, 2025 17:02 --> TheBlueMatt and others added 6 commits February 4, 2026 13:51 Avoid creating <= 64-byte transactions in most functional tests. b663f62 [test] Separate 64B and 63B tx size tests 98244e6 consensus: make 64 bytes transactions invalid b975047 qa: unit tests for BIP54 rule on 64-byte transactions (with JSON test… &hellip; bccf3bb … vectors) This adds tests exercising the bounds of the checks on the invalid transaction size, for various types of transactions (legacy, Segwit, bytes in input/output to get to 64 bytes) as well as sanity checking against some known historical violations. Thanks to Chris Stewart for digging up the historical violations to this rule. scripted-diff: qa: rename constant for BIP54 sigops limit &hellip; 09123d8 It's not a standardness limit anymore, it was made consensus. Thanks to Anthony Towns for the scripted diff script. -BEGIN VERIFY SCRIPT- sed -i 's/MAX_STD_LEGACY_SIGOPS/MAX_TX_BIP54_SIGOPS/g' $(git grep -l MAX_STD_LEGACY_SIGOPS) sed -i 's/signature operations in validating a transaction./signature operations in a single transaction, per BIP54./' test/functional/test_framework/script_util.py -END VERIFY SCRIPT- Co-Authored-by: Anthony Towns <[email protected]> qa: end-to-end test all BIP54 mitigations &hellip; 55cd9a5 The previously introduced unit tests extensively test the specific implementation of each mitigation. This functional test complements them by end-to-end testing all mitigations. For the added timestamp constraints, it mimicks how they would get exploited (by implementing pseudo timewarp and Murch-Zawy attacks) and demonstrates those exploits are not possible anymore after BIP54 activates. darosior force-pushed the 2509_inquisition_consensus_cleanup branch from 0d298f5 to 55cd9a5 Compare February 4, 2026 19:18 darosior commented Copy link Copy Markdown Author Would simply adding the block's coinbase's locktime to the output of verbosity-1 getblock be sufficient then? diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp index bbe401fcc6c..78062c74e6f 100644 --- a/src/rpc/blockchain.cpp +++ b/src/rpc/blockchain.cpp @@ -183,6 +183,7 @@ UniValue blockToJSON(BlockManager& blockman, const CBlock& block, const CBlockIn result.pushKV("strippedsize", (int)::GetSerializeSize(TX_NO_WITNESS(block))); result.pushKV("size", (int)::GetSerializeSize(TX_WITH_WITNESS(block))); result.pushKV("weight", (int)::GetBlockWeight(block)); + result.pushKV("cblocktime", block.vtx.at(0)->nLockTime); UniValue txs(UniValue::VARR); switch (verbosity) { @@ -724,6 +725,7 @@ static RPCHelpMan getblock() {RPCResult::Type::NUM, "version", "The block version"}, {RPCResult::Type::STR_HEX, "versionHex", "The block version formatted in hexadecimal"}, {RPCResult::Type::STR_HEX, "merkleroot", "The merkle root"}, + {RPCResult::Type::NUM, "locktime", "The coinbase transaction's locktime value"}, {RPCResult::Type::ARR, "tx", "The transaction ids", {{RPCResult::Type::STR_HEX, "", "The transaction id"}}}, {RPCResult::Type::NUM_TIME, "time", "The block time expressed in " + UNIX_EPOCH_TIME}, I've tested this on mainnet with your snippet from earlier and it's reasonably performant. https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg Per se, unless I'm missing something, I don't think the value of the nSequence field needs to be set to a precise value and the whole field could be even “free" up field either for (a) for an extra nonce or (b) as a space where to fit a new commitment structure in the future (and that's particularly interesting as it would work even if there are no segwit txn in the block cf. BIP141). cc @darosior There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . if (cmpctblock.header.IsNull() || (cmpctblock.shorttxids.empty() && cmpctblock.prefilledtxn.empty())) return READ_STATUS_INVALID; Sanitizing that the received coinbase is respecting the new rules of consensus avoids to store cmpct block state for a block that will be overall consenus invalid (note the validation of the coinbase is already lax afaict). There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was a problem hiding this comment. The reason will be displayed to describe this comment to others. Learn more . There was an error while loading. Please reload this page . Yeah, seems like -- it takes about 3 times as long as the dedicated RPC for me in a quick test, but that's good enough for how much simpler it is. I found "cblocktime" confusing ( CBlock time?), maybe tx0_locktime ? Also should report whether nseq is final or not. Could also just report "bip54_coinbase_readiness": true/false . I messed around with the dedicated approach some more; it looks like if you add a dedicated ReadBlockCoinbaseOnly method to block storage, which just reads the header and coinbase tx, but not the rest of the block, then the dedicated rpc gets a massive speedup. My figures are: I'll update I've updated my branch , but the getblock 1 approach seems like the sweet spot. (It's probably also faster if your node doesn't have quite as convoluted a setup as mine) There was an error while loading. Please reload this page . Indeed, it reads like "c block time", cb_locktime should work. Also should report whether nseq is final or not. Could also just report "bip54_coinbase_readiness": true/false . Ideally we keep it generic enough so it can be PR'd to Bitcoin Core indepedent of BIP54. Maybe add a coinbase field to getblock with (a guaranteed to be small subset of) fields similar to the CoinbaseTx struct from bitcoin#33819 : version , sequence and lock_time . Could add an is_final bool for convenience, given its relevance. https://groups.google.com/g/bitcoindev/c/6TTlDwP2OQg Per se, unless I'm missing something, I don't think the value of the nSequence field needs to be set @ariard i have replied to you on the mailing list . TL;DR: it seems my explanation was lacking and you missed the purpose for making sure nSequence is never final. Note also we don't constrain it to be a specific value. On the contrary it can be anything as long it's not the specific final value. There was an error while loading. Please reload this page . @darosior I think I got your idea with the assumption that BIP54 can be buried in the future, and the check to be applied on all historical coinbase transactions, therefore ensuring any old coinbase cannot be used to generate a post-BIP54 action height identifier collision. Replied, I’m still thinking you can make a simpler assumption by just relying on the PoW ordering mechanism itself. There can be only and only one block valid at a given chain height. Yes, I see it doesn’t have to be set to a specific value. See the point on protecting the coinbase nSequence field. It’s of independent interest, that the check is kept or not. Historical coinbase transactions on mainnet, testnet3, testnet4 and signet all fail to comply with bip54 rules, so that approach isn't possible. Okay so up to Darosior what he meant here on the ml: "For instance, if BIP 54 activation height ever gets buried in Bitcoin Core, the BIP 30 check could just be disabled past this height instead of having to figure out if we are on a chain that contains the historical BIP 34 activation block hash [3]. So strictly a buried activation height, nothing like a retroactive validation from genesis like it was done for BIP30. Point is the additional check in nsequence field is superflous imho. e0463b4 rpc: add coinbase_tx field to getblock (Sjors Provoost) Pull request description: This adds a `coinbase_tx` field to the `getblock` RPC result, starting at verbosity level 1. It contains only fields guaranteed to be small, i.e. not the outputs. Initial motivation for this was to more efficiently scan for BIP54 compliance. Without this change, it requires verbosity level 2 to get the coinbase, which makes such scan very slow. See bitcoin-inquisition#99 (comment) . Adding these fields should be useful in general though and hardly makes the verbosity 1 result longer. ``` bitcoin rpc help getblock getblock "blockhash" ( verbosity ) If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'. If verbosity is 1, returns an Object with information about block <hash>. If verbosity is 2, returns an Object with information about block <hash> and information about each transaction. ... Result (for verbosity = 1): { (json object) "hash" : "hex", (string) the block hash (same as provided) "confirmations" : n, (numeric) The number of confirmations, or -1 if the block is not on the main chain "size" : n, (numeric) The block size "strippedsize" : n, (numeric) The block size excluding witness data "weight" : n, (numeric) The block weight as defined in BIP 141 "coinbase_tx" : { (json object) Coinbase transaction metadata "version" : n, (numeric) The coinbase transaction version "locktime" : n, (numeric) The coinbase transaction's locktime (nLockTime) "sequence" : n, (numeric) The coinbase input's sequence number (nSequence) "coinbase" : "hex", (string) The coinbase input's script "witness" : "hex" (string, optional) The coinbase input's first (and only) witness stack element, if present }, "height" : n, (numeric) The block height or index "version" : n, (numeric) The block version ... ``` ``` bitcoin rpc getblock 000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6 1 ``` ```json { "hash": "000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6", "confirmations": 2, "height": 935113, "version": 561807360, "...": "...", "weight": 3993624, "coinbase_tx": { "version": 2, "locktime": 0, "sequence": 4294967295, "coinbase": "03c9440e04307c84692f466f756e6472792055534120506f6f6c202364726f70676f6c642ffabe6d6d9a8624235259d3680c972b0dd42fa3fe1c45c5e5ae5a96fe10c182bda17080e70100000000000000184b17d3f138020000000000", "witness": "0000000000000000000000000000000000000000000000000000000000000000" }, "tx": [ "70eb053340c7978c5aa1b34d75e1ba9f9d1879c09896317f306f30c243536b62", "5bcf8ed2900cb70721e808b8977898e47f2c9001fcee83c3ccd29e51c7775dcd", "3f1991771aef846d7bb379d2931cccc04e8421a630ec9f52d22449d028d2e7f4", "..." ] } ``` ACKs for top commit: sedited: Re-ACK e0463b4 darosior: re-utACK e0463b4 Tree-SHA512: 1b3e7111e6a0edffde8619c49b3e9bca833c8e90e416defc66811bd56dd00d45b69a84c8fd9715508f4e6515f77ac4fb5c59868ab997ae111017c78c05b74ba3 This was referenced Mar 13, 2026 A couple improvements to BIP 54 test vectors #110 Merged BIP 54 test vectors improvements following review in Inquisition bitcoin/bips#2122 Merged Kino1994 pushed a commit to Kino1994/bitcoin-full-history that referenced this pull request Jun 28, 2026 Merge bitcoin/bitcoin#34512 : rpc: add coinbase_tx field to getblock &hellip; e37ef4d 83b9757 rpc: add coinbase_tx field to getblock (Sjors Provoost) Pull request description: This adds a `coinbase_tx` field to the `getblock` RPC result, starting at verbosity level 1. It contains only fields guaranteed to be small, i.e. not the outputs. Initial motivation for this was to more efficiently scan for BIP54 compliance. Without this change, it requires verbosity level 2 to get the coinbase, which makes such scan very slow. See bitcoin-inquisition/bitcoin#99 (comment) . Adding these fields should be useful in general though and hardly makes the verbosity 1 result longer. ``` bitcoin rpc help getblock getblock "blockhash" ( verbosity ) If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'. If verbosity is 1, returns an Object with information about block <hash>. If verbosity is 2, returns an Object with information about block <hash> and information about each transaction. ... Result (for verbosity = 1): { (json object) "hash" : "hex", (string) the block hash (same as provided) "confirmations" : n, (numeric) The number of confirmations, or -1 if the block is not on the main chain "size" : n, (numeric) The block size "strippedsize" : n, (numeric) The block size excluding witness data "weight" : n, (numeric) The block weight as defined in BIP 141 "coinbase_tx" : { (json object) Coinbase transaction metadata "version" : n, (numeric) The coinbase transaction version "locktime" : n, (numeric) The coinbase transaction's locktime (nLockTime) "sequence" : n, (numeric) The coinbase input's sequence number (nSequence) "coinbase" : "hex", (string) The coinbase input's script "witness" : "hex" (string, optional) The coinbase input's first (and only) witness stack element, if present }, "height" : n, (numeric) The block height or index "version" : n, (numeric) The block version ... ``` ``` bitcoin rpc getblock 000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6 1 ``` ```json { "hash": "000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6", "confirmations": 2, "height": 935113, "version": 561807360, "...": "...", "weight": 3993624, "coinbase_tx": { "version": 2, "locktime": 0, "sequence": 4294967295, "coinbase": "03c9440e04307c84692f466f756e6472792055534120506f6f6c202364726f70676f6c642ffabe6d6d9a8624235259d3680c972b0dd42fa3fe1c45c5e5ae5a96fe10c182bda17080e70100000000000000184b17d3f138020000000000", "witness": "0000000000000000000000000000000000000000000000000000000000000000" }, "tx": [ "70eb053340c7978c5aa1b34d75e1ba9f9d1879c09896317f306f30c243536b62", "5bcf8ed2900cb70721e808b8977898e47f2c9001fcee83c3ccd29e51c7775dcd", "3f1991771aef846d7bb379d2931cccc04e8421a630ec9f52d22449d028d2e7f4", "..." ] } ``` ACKs for top commit: sedited: Re-ACK 83b9757 darosior: re-utACK 83b9757 Tree-SHA512: 1b3e7111e6a0edffde8619c49b3e9bca833c8e90e416defc66811bd56dd00d45b69a84c8fd9715508f4e6515f77ac4fb5c59868ab997ae111017c78c05b74ba3 BigcoinBGC pushed a commit to BigcoinBGC/bigcoin that referenced this pull request Jun 30, 2026 Merge bitcoin/bitcoin#34512 : rpc: add coinbase_tx field to getblock &hellip; db4126b 33a69df rpc: add coinbase_tx field to getblock (Sjors Provoost) Pull request description: This adds a `coinbase_tx` field to the `getblock` RPC result, starting at verbosity level 1. It contains only fields guaranteed to be small, i.e. not the outputs. Initial motivation for this was to more efficiently scan for BIP54 compliance. Without this change, it requires verbosity level 2 to get the coinbase, which makes such scan very slow. See bitcoin-inquisition/bitcoin#99 (comment) . Adding these fields should be useful in general though and hardly makes the verbosity 1 result longer. ``` bitcoin rpc help getblock getblock "blockhash" ( verbosity ) If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'. If verbosity is 1, returns an Object with information about block <hash>. If verbosity is 2, returns an Object with information about block <hash> and information about each transaction. ... Result (for verbosity = 1): { (json object) "hash" : "hex", (string) the block hash (same as provided) "confirmations" : n, (numeric) The number of confirmations, or -1 if the block is not on the main chain "size" : n, (numeric) The block size "strippedsize" : n, (numeric) The block size excluding witness data "weight" : n, (numeric) The block weight as defined in BIP 141 "coinbase_tx" : { (json object) Coinbase transaction metadata "version" : n, (numeric) The coinbase transaction version "locktime" : n, (numeric) The coinbase transaction's locktime (nLockTime) "sequence" : n, (numeric) The coinbase input's sequence number (nSequence) "coinbase" : "hex", (string) The coinbase input's script "witness" : "hex" (string, optional) The coinbase input's first (and only) witness stack element, if present }, "height" : n, (numeric) The block height or index "version" : n, (numeric) The block version ... ``` ``` bitcoin rpc getblock 000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6 1 ``` ```json { "hash": "000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6", "confirmations": 2, "height": 935113, "version": 561807360, "...": "...", "weight": 3993624, "coinbase_tx": { "version": 2, "locktime": 0, "sequence": 4294967295, "coinbase": "03c9440e04307c84692f466f756e6472792055534120506f6f6c202364726f70676f6c642ffabe6d6d9a8624235259d3680c972b0dd42fa3fe1c45c5e5ae5a96fe10c182bda17080e70100000000000000184b17d3f138020000000000", "witness": "0000000000000000000000000000000000000000000000000000000000000000" }, "tx": [ "70eb053340c7978c5aa1b34d75e1ba9f9d1879c09896317f306f30c243536b62", "5bcf8ed2900cb70721e808b8977898e47f2c9001fcee83c3ccd29e51c7775dcd", "3f1991771aef846d7bb379d2931cccc04e8421a630ec9f52d22449d028d2e7f4", "..." ] } ``` ACKs for top commit: sedited: Re-ACK 33a69df darosior: re-utACK 33a69df Tree-SHA512: 1b3e7111e6a0edffde8619c49b3e9bca833c8e90e416defc66811bd56dd00d45b69a84c8fd9715508f4e6515f77ac4fb5c59868ab997ae111017c78c05b74ba3 This was referenced Jul 22, 2026 BIP 54: return the appropriate type of error according to activation status in mempool submission #118 Closed Implement BIP 54 (Consensus Cleanup) without mainnet activation darosior/bitcoin#8 Closed Implement BIP 54 (Consensus Cleanup) without mainnet activation bitcoin/bitcoin#35793 Open Kino1994 pushed a commit to Kino1994/bitcoin-full-history that referenced this pull request Aug 19, 2026 Merge bitcoin/bitcoin#34512 : rpc: add coinbase_tx field to getblock &hellip; ad89836 e0463b4e8c25f8a5fe10999f2821e7b221d2e40a rpc: add coinbase_tx field to getblock (Sjors Provoost) Pull request description: This adds a `coinbase_tx` field to the `getblock` RPC result, starting at verbosity level 1. It contains only fields guaranteed to be small, i.e. not the outputs. Initial motivation for this was to more efficiently scan for BIP54 compliance. Without this change, it requires verbosity level 2 to get the coinbase, which makes such scan very slow. See bitcoin-inquisition/bitcoin#99 (comment) . Adding these fields should be useful in general though and hardly makes the verbosity 1 result longer. ``` bitcoin rpc help getblock getblock "blockhash" ( verbosity ) If verbosity is 0, returns a string that is serialized, hex-encoded data for block 'hash'. If verbosity is 1, returns an Object with information about block <hash>. If verbosity is 2, returns an Object with information about block <hash> and information about each transaction. ... Result (for verbosity = 1): { (json object) "hash" : "hex", (string) the block hash (same as provided) "confirmations" : n, (numeric) The number of confirmations, or -1 if the block is not on the main chain "size" : n, (numeric) The block size "strippedsize" : n, (numeric) The block size excluding witness data "weight" : n, (numeric) The block weight as defined in BIP 141 "coinbase_tx" : { (json object) Coinbase transaction metadata "version" : n, (numeric) The coinbase transaction version "locktime" : n, (numeric) The coinbase transaction's locktime (nLockTime) "sequence" : n, (numeric) The coinbase input's sequence number (nSequence) "coinbase" : "hex", (string) The coinbase input's script "witness" : "hex" (string, optional) The coinbase input's first (and only) witness stack element, if present }, "height" : n, (numeric) The block height or index "version" : n, (numeric) The block version ... ``` ``` bitcoin rpc getblock 000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6 1 ``` ```json { "hash": "000000000000000000013c986f9aebe800a78454c835ccd07ecae2650bfad3f6", "confirmations": 2, "height": 935113, "version": 561807360, "...": "...", "weight": 3993624, "coinbase_tx": { "version": 2, "locktime": 0, "sequence": 4294967295, "coinbase": "03c9440e04307c84692f466f756e6472792055534120506f6f6c202364726f70676f6c642ffabe6d6d9a8624235259d3680c972b0dd42fa3fe1c45c5e5ae5a96fe10c182bda17080e70100000000000000184b17d3f138020000000000", "witness": "0000000000000000000000000000000000000000000000000000000000000000" }, "tx": [ "70eb053340c7978c5aa1b34d75e1ba9f9d1879c09896317f306f30c243536b62", "5bcf8ed2900cb70721e808b8977898e47f2c9001fcee83c3ccd29e51c7775dcd", "3f1991771aef846d7bb379d2931cccc04e8421a630ec9f52d22449d028d2e7f4", "..." ] } ``` ACKs for top commit: sedited: Re-ACK e0463b4e8c25f8a5fe10999f2821e7b221d2e40a darosior: re-utACK e0463b4e8c25f8a5fe10999f2821e7b221d2e40a Tree-SHA512: 1b3e7111e6a0edffde8619c49b3e9bca833c8e90e416defc66811bd56dd00d45b69a84c8fd9715508f4e6515f77ac4fb5c59868ab997ae111017c78c05b74ba3 --> This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters Show hidden characters to join this conversation on GitHub . Already have an account? Sign in to comment --> Uh oh! There was an error while loading. Please reload this page .

ARCHIVED SOURCE url: https://www.learnbitcoin.com/glossary/great-consensus-cleanup canonical: https://www.learnbitcoin.com/glossary/great-consensus-cleanup captured_utc: 2026-11-06T03:35:06.109Z http_status: 200 method: direct extractor: scrut-extract-2 truncated: false --- A proposed soft fork, BIP-54, that bundles fixes for four old defects in Bitcoin's consensus rules: the time warp attack, blocks built to take minutes to validate, 64-byte transactions that confuse Merkle proofs, and the duplicate-coinbase check nodes still carry for BIP-30. Matt Corallo drafted it in 2019; Antoine Poinsot revived it in 2024 and the finished text was numbered in 2025. Not activated. 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 as a precaution, after testnet4 exposed pool software that stamped blocks from its own clock rather than the template; under a sustained attack it costs about three seconds a block. How this rule got from ArtForz's 2011 forum post to BIP-54, and how every seam in Bitcoin's history measures against both grace periods, is told in The Time Warp . 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 time warp rule since version 29.0, the signature-operation limit since 30.0 and the negative-window rule since 32.1, 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 November 2026 the chain parameters hold no activation for it. The topic timeline: Time warp, timestamps and the consensus cleanup (58 threads). Was: The entry said Bitcoin Core 29.0 refuses to build templates that break the timestamp rules, plural, and repeated the testnet4 reason and the two-second cost for the two-hour grace. Now: 29.0 covers the time warp rule; the negative-window rule reached Bitcoin Core's templates in 32.1 (PR #35949, October 2026). Two hours was a precaution, at a cost of about three seconds a block under a sustained attack. Details Published 19 October 2026 . Revised 5 November 2026 . One correction logged for this page .