From 47a2d725390a28d8fee0132bbba28e6ad7f6986f Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Fri, 15 May 2026 11:09:46 -0400 Subject: [PATCH] bip-0054: less redundancy in 64-byte rationale, move caching risk to footnote --- bip-0054.md | 39 +++++++++++++++++++-------------------- 1 file changed, 19 insertions(+), 20 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index 5734da14..2ac74c8d 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -41,7 +41,7 @@ pressures and leading to reduced network security. In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it possible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not -part of a block, by pretending a 64-byte block transaction is actually an inner node. Invalidating +part of a block, by pretending a 64-byte block transaction is actually an inner node[^9]. Invalidating 64-byte transactions addresses this vulnerability without requiring users of SPV verifiers to deploy one of the available mitigations, or even to know one is necessary in the first place. @@ -104,20 +104,16 @@ increases the preparation cost of an attack, making it uneconomical for a miner[ 2500 was chosen as the tightest value that did not make any non-pathological standard transaction invalid[^7]. -In the presence of 64-byte transactions a block header's Merkle root may be valid for different sets -of transactions. This is because, in the Merkle tree construction, a 64-byte value may be -interpreted either as a transaction or as the concatenation of two 32-byte hashes. Reinterpreting a -transaction as a node allows creating a valid Merkle proof for a transaction not included in a -block. 64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one -that burns them. 64-byte transactions have also been non-standard since 2019 and unused since 2016. -It was suggested that the known vulnerabilities could instead be mitigated by committing to the -Merkle tree depth in the header's version field[^8], to avoid introducing a "seam". The authors -believe it is preferable to address the root cause by invalidating 64-byte transactions, fixing the -vulnerability without developers of SPV verifiers having to implement the mitigation or to know it -is necessary in the first place. See [this post][64 bytes debate] for an attempt at summarizing the -arguments for both sides of this debate. Reinterpreting Merkle tree nodes as transactions could be -used to cause a vulnerable node to fall out of consensus[^9]. There are better ways to mitigate this -issue on its own, but it is also addressed as a byproduct of invalidating 64-byte transactions. +64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that +burns them. They have also been non-standard since 2019 and never been used since 2016. Several +alternatives to invalidating them were previously proposed. Some believe the improvements for users +of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid +witness-stripped transaction sizes. Others have suggested that the known vulnerabilities could +instead be mitigated by committing to the Merkle tree depth in the header's version field[^8]. The +authors believe it is preferable to address the root cause by invalidating 64-byte transactions, +fixing the vulnerability without developers of SPV verifiers having to implement the mitigation or +to know it is necessary in the first place. See [this post][64 bytes debate] for an attempt at +summarizing the arguments for both sides of this debate. Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity @@ -212,10 +208,14 @@ standard transaction size before running into the newly introduced limit. To run 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. -[^8]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric -version]. -[^9]: Bitcoin Core versions between 0.13.0 and 0.13.2 implemented caching that made it vulnerable to -this attack. See [this writeup][Suhas Merkle] by Suhas Daftuar for a detailed explanation. +[^8]: By Sergio Demian Lerner in a [blog post][Sergio post]. +[^9]: 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][Suhas Merkle] 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. [^10]: See [here][BIP34 list] for a full list of the heights of historical blocks including a valid bip-0034 height commitment and the corresponding future block height. [^11]: Technically it could be argued a duplicate could in principle always be possible before block @@ -242,7 +242,6 @@ have to be perpetuated for the Consensus Cleanup. [ML thread validation time]: https://gnusha.org/pi/bitcoindev/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com [Suhas Merkle]: https://gnusha.org/pi/bitcoindev/CAFp6fsGtEm9p-ZQF_XqfqyQGzZK7BS2SNp2z680QBsJiFDraEA@mail.gmail.com [Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design -[Eric version]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/37 [64 bytes debate]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41 [BIP34 list]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4 [Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core