From f1f1c36ff24157c6c7de698a90fa3fff4ab8b337 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 17 May 2026 17:43:21 -0400 Subject: [PATCH] bip-0054: add a footnote with known workarounds for SPV verifiers --- bip-0054.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/bip-0054.md b/bip-0054.md index 3f6dcd95..7eb277f0 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -43,7 +43,7 @@ interpreted both as an intermediate node in the tree and as a leaf in the tree. 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[^9]. Invalidating 64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or -any other user of Merkle proofs, to rely on one of the available workarounds or even to know one is +any other user of Merkle proofs, to rely on one of the available workarounds[^13] or even to know one is necessary in the first place. Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until @@ -228,6 +228,13 @@ notably of Bitcoin Core but also of all other implementations the authors are aw where [bip-0034][BIP34] violations have been manually inspected (see [here][Core validation.cpp BIP34]). Without the guarantee given by enforcing the timelock on coinbase transactions, this would have to be perpetuated for the Consensus Cleanup. +[^13]: 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][Sergio +post]. 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][Sergio +MERKLEBLOCK] for a full description. [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki [BIP-XXXX]: https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki @@ -243,6 +250,7 @@ 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 +[Sergio MERKLEBLOCK]: https://bitslog.com/2018/08/21/simple-change-to-the-bitcoin-merkleblock-command-to-protect-from-leaf-node-weakness-in-transaction-merkle-tree/ [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