This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst\ncase block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without\nbip-0030 validation.
\nThis proposal addresses a number of long-standing vulnerabilities and weaknesses in the Bitcoin\nprotocol. Bundling these fixes together amortizes the fixed cost of deploying a Bitcoin soft fork.
\nThe timewarp bug makes it possible for a majority-hashrate attacker to arbitrarily\nlower mining difficulty, and therefore arbitrarily increase the block rate. In the worst case, an\nattacker can bring down the difficulty to its minimum within 38 days of starting the attack. Besides\nempowering a 51% attacker, the presence of this bug makes it harder to reason about miners'\nincentives. Accelerating the block rate allows an attacker to steal block subsidy from future\nminers and increases available block space. It may be in the interest of short-sighted users and\nminers to exploit this vulnerability to materially increase the block rate without fatally hurting\nthe network.
\nSpecially crafted blocks may be expensive to process, taking up to several\nminutes to validate even on high-end devices, and up to a few hours on lower-end devices. Long block\nvalidation times are a nuisance to users, increasing the cost to independently fully validate the\nconsensus rules. In addition they can be used by miners to attack their competition, creating\nperverse incentives, centralization pressures and leading to reduced network security.
\nIn computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be\ninterpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it\npossible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not\npart of a block, by pretending a 64-byte block transaction is actually an inner node[^9]. Invalidating\n64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or\nany other user of Merkle proofs, to rely on one of the available workarounds[^13] or even to know one is\nnecessary in the first place.
\nSince bip-0034 activation, explicit bip-0030 validation is not necessary until\nblock height 1,983,702[^0]. Resuming bip-0030 validation would unnecessarily increase block\nvalidation overhead and preclude alternative full node designs (such as bip-0182 Utreexo).\nEnforcing that new coinbase transactions are different from the early bip-0034 violations\nmakes it possible to get rid of bip-0030 validation forever.
\nFor all blocks after activation the following new rules apply.
\nGiven a block at height N:
N % 2016 is equal to 0, the timestamp of the block must be set to a value higher than or\nequal to the value of the timestamp of block at height N-1 minus 7200 (TN ≥\nTN−1 − 7200) seconds;N % 2016 is equal to 2015, the timestamp of the block must be set to a value higher than\nor equal to the value of the timestamp of the block at height N-2015 (TN ≥\nTN−2015).A limit is set on the number of signature operations present in the scripts used to validate a\ntransaction. It applies to all transactions in the block except the coinbase transaction[^1]. For\neach input in the transaction, count the number of signature operations from CHECKSIG(VERIFY) and CHECKMULTISIG(VERIFY) in the input\nscriptSig and previous output's scriptPubKey, including the P2SH redeemScript. If the total summed\nover all transaction inputs is strictly higher than 2500, the transaction is invalid. The accounting is the\nsame as for bip-0016, evaluating the scriptSig, scriptPubKey, and P2SH redeemScript\nseparately:
CHECKSIG and CHECKSIGVERIFY each count as 1 signature operation, whether or not they are evaluated.CHECKMULTISIG and CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operations, whether or not they are evaluated.CHECKMULTISIG and CHECKMULTISIGVERIFY are counted as 20 signature operations, whether or not they are evaluated.Transactions whose witness-stripped serialized size is exactly 64 bytes are invalid.
\nThe coinbase transaction's nLockTime field must be set to the height of the block minus 1[^2]\nand 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\nthe timewarp and Murch–Zawy vulnerabilities[^3]. The latter poses mostly theoretical concerns but is\nextremely low risk to fix: the duration of an adjustment period has never been, and should never be,\nnegative. The former is fixed by preventing the timestamp of the first block of a difficulty period\nfrom being lower than the previous block's, with a two-hour grace period. A previous\nproposal to fix the timewarp attack used a ten-minute grace period instead, and this\napproach has been adopted for testnet4. Out of an abundance of caution and because it only trivially worsens the\nblock rate increase under attack, a two-hour grace period is used here[^4].
\nDisabling some Script operations and functionalities was previously proposed to reduce\nthe worst case block validation time but was met with resistance due to confiscation concerns[^5]. A\ndelicate balance needs to be struck between minimizing the confiscation risks of a mitigation, even\nif merely theoretical, and bounding the costs one could impose on all other users of the system. To\nthat end, limiting potentially executed signature operations targets the exact harmful behaviour while\npreserving maximal flexibility in Script usage.\nSuch a limit reduces the worst case block validation time by a factor of 40 and drastically\nincreases the preparation cost of an attack, making it uneconomical for a miner[^6]. The maximum of\n2500 was chosen as the tightest value that did not make any non-pathological standard transaction\ninvalid[^7].
\n64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that\nburns them. They have also been non-standard since 2019 and never been used since 2016. Several\nalternatives to invalidating them were previously proposed. Some believe the improvements for users\nof Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid\nwitness-stripped transaction sizes (discussion here). Others have suggested instead committing to the Merkle\ntree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond\nto a valid serialisation for a Bitcoin transaction[^14]. These options make some of the available\nworkarounds[^13] easier to deploy. The authors believe it is preferable to address the root cause by\ninvalidating 64-byte transactions. This fixes the vulnerability for users relying on Merkle proofs\nof non-64-byte transactions, without requiring a workaround.
\nThe nLockTime field of transactions is a natural place to store a block height and is currently\nunused in coinbase transactions. Using it to enforce that new coinbase transactions differ from\nearly bip-0034 violations also allows applications to recover the block height without\nhaving to parse Script. Leveraging the existing timelock mechanism makes the check self-contained:\nthe same coinbase transaction cannot have been valid in a previous block[^11]. This simplifies both\nreasoning and client implementation, since the bip-0030 check can be skipped entirely past\nConsensus Cleanup activation, regardless of the bip-0034 activation status[^12]. One person\nraised the concern that the nLockTime field would be an ideal extranonce\nfor ASIC controllers if such controllers ever became a bottleneck in mining operations. Others\nreplied that the same benefits could be achieved by using a dummy output\ninstead, should that ever become necessary. The authors believe the\nbenefits of using nLockTime to differentiate coinbase transactions outweigh the theoretical\ncost 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\nrules proposed in this BIP but not under the existing Bitcoin consensus rules. As a consequence\nthese changes are backward-compatible with non-upgraded node software. That said, the authors\nstrongly encourage node operators to upgrade in order to fully validate all consensus rules.
\nBitcoin Core version 29.0 and later will not generate a block template that violates\nthe timestamp restrictions introduced in this BIP. Although it would be extremely unlikely due to\nthe grace period used in this proposal, miners should use the curtime or mintime field from the\ngetblocktemplate result for their block's timestamp to make sure they always create blocks valid\naccording to this proposal. Note this is not a new requirement: using a timestamp lower than the\nmintime 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\ntransaction that violates the signature operations limit introduced in this BIP.
\nBitcoin Core version 0.16.1 and later will neither relay nor create block templates\nthat include transactions whose witness-stripped serialized size is exactly 64 bytes.
\nThe coinbase transaction is usually crafted by mining pool software. To the best of the authors'\nknowledge, there does not exist an open source reference broadly in use today for such software.\nWe encourage mining pools to update their software to craft coinbase transactions that are\nforward-compatible with the changes proposed in this BIP.
\nAn implementation of BIP54 for Bitcoin Core is available here.
\nDocumented test vectors are available here for all mitigations\nintroduced in this BIP.
\nThis document builds upon an earlier proposal by Matt Corallo.
\nThe authors would like to thank everyone involved in researching the most appropriate mitigation for\neach of these bugs. We would like to thank in particular Anthony Towns and Sjors Provoost for their\ndirect contributions to this proposal, as well as @0xb10c and Brian Groll for providing the authors\nwith data to analyze the proposed mitigations. Thanks to Chris Stewart for digging up historical\nviolations to the new transaction size rule, which are partially reused in this BIP's test vectors.
\nThis document is licensed under the Creative Commons CC0 1.0 Universal license.
\n[^0]: Block 1,983,702 is the earliest future block which could contain a duplicate coinbase\ntransaction while still respecting bip-0034. See this post for a list\nof all such future blocks.\n[^1]: Technically this limit cannot apply to a coinbase transaction as the size of its sole\ninput's scriptSig is limited.\n[^2]: The locktime validation, which is also performed for coinbase transactions, enforces that the\nnLockTime value is the last block at which a transaction is invalid, not the first one at which it\nis valid.\n[^3]: The timewarp attack is described here and the Murch–Zawy attack here.\n[^4]: The testnet4 difficulty exception pushed blocks' timestamps in the future when abused,\nrevealing how some broken pool software may produce blocks that don't respect a 10 minutes grace\nperiod. Some raised concerns similarly broken software might be used on\nmainnet. Using a grace period of 2 hours instead of 10 minutes only reduces the expected block\ninterval time under attack by ~2.2 seconds. See this post for more.\n[^5]: The argument is about someone having a timelocked presigned transaction using some of those\nfeatures in its output script. The transaction cannot be mined before activation. Such outputs would\nnot be covered by an amnesty for old UTxOs. See for instance here and\nhere for discussions on this topic.\n[^6]: It is important to reduce the worst case block validation time as well as the ratio of\nvalidation time imposed over preparation cost. The former is to limit the damages an externally\nmotivated attacker can do. The latter is to disincentivize miners slowing down their competition by\nmining expensive blocks. See this thread for more.\n[^7]: A non-pathological transaction would have a public key per signature operation and at least\none signature per input. Per standardness a single P2SH input may not have more than 15 signature\noperations. Even by using 1-of-15 CHECKMULTISIGs a transaction would bump against the maximum\nstandard transaction size before running into the newly introduced limit. To run against the newly\nintroduced limit but not the transaction size a transaction would need to spend P2SH inputs with a\nredeem script similar to CHECKSIG DROP CHECKSIG DROP .... This type of redeem script serves no\npurpose beyond increasing its validation cost, which is exactly what this proposal aims to mitigate.\n[^8]: By Sergio Demian Lerner in a blog post.\n[^9]: Conversely, pretending that the inner nodes on one level of the tree are the actual block\ntransactions is another source of complexity for full node implementations, which previously\nresulted in consensus bugs. For instance, Bitcoin Core versions between 0.13.0 and 0.13.2\nimplemented caching that made it vulnerable to this attack. See this writeup by\nSuhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but\nthe issue is largely orthogonal to this proposal: it is fundamentally about caching validation\nstatus for malleable blocks.\n[^11]: Technically it could be argued a duplicate could in principle always be possible before block\n31,001 when nLockTime enforcement was originally soft-forked. But treating\ncoinbase transactions as not having duplicate past Consensus Cleanup activation would be consistent\nfor any implementation which enforces nLockTime from the genesis block, which is the behaviour\nnotably of Bitcoin Core but also of all other implementations the authors are aware of.\n[^12]: For instance Bitcoin Core only disables bip-0030 validation for a specific chain\nwhere bip-0034 violations have been manually inspected (see here). Without the guarantee given by enforcing the timelock on coinbase transactions, this would\nhave to be perpetuated for the Consensus Cleanup.\n[^13]: The authors are aware of three workarounds for SPV verifiers. The first is to request a\nMerkle proof for the coinbase transaction in addition to the transaction of interest, to infer the\ndepth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a\nvalid 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\nprovided as the single-SHA256 of their preimage, instead of the double-SHA256. See here for a full description.\n[^14]: Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list).