From 9ec73fc6edd878c0df3676cf66e03abbdc00f889 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Tue, 7 Jul 2026 14:57:40 -0400 Subject: [PATCH 1/2] bip-0054: mention Jeremy's alternative proposal in rationale --- bip-0054.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index ab88f80d4c..bbac6c4ffe 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -105,12 +105,12 @@ invalid[^7]. burns them. They have also been non-standard since 2019 and never been used since 2016. Several alternatives to invalidating them were previously proposed. Some believe the improvements for users of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid -witness-stripped transaction sizes. Others have suggested instead committing to the Merkle -tree depth in the header's version field[^8], which would make one workaround for a known -vulnerability easier to deploy. The authors believe it is preferable to address the root cause by +witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle +tree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond +to a valid serialization for a Bitcoin transaction[^14]. 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, fixing the vulnerability without Merkle proof users having to -rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes -debate] for an attempt at summarizing the arguments for both sides of this debate. +rely on any workaround or even know one is necessary in the first place. 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 @@ -236,6 +236,7 @@ valid serialisation of a Bitcoin transaction. More details about these are avail 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. +[^14]: [Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list)][Rubin node preimages]. [Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki @@ -264,3 +265,4 @@ MERKLEBLOCK] for a full description. [Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459 [miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk [ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/ +[Rubin node preimages]: https://gnusha.org/pi/bitcoindev/f97afcc5-54ba-4284-8e9b-e8c35c7101f6n@googlegroups.com/ From 7c7e2f10a4ed096b10cd3ea0fd966286057f9c52 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Tue, 7 Jul 2026 15:32:17 -0400 Subject: [PATCH 2/2] bip-0054: an SPV verifier that supports 64-byte txs would have to be modified --- bip-0054.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index bbac6c4ffe..bf5e6527c3 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -107,10 +107,10 @@ alternatives to invalidating them were previously proposed. Some believe the imp of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle tree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond -to a valid serialization for a Bitcoin transaction[^14]. These options make some of the available +to a valid serialisation for a Bitcoin transaction[^14]. 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, fixing the vulnerability without Merkle proof users having to -rely on any workaround or even know one is necessary in the first place. +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