BIP 54: mention recent ML discussion and 64-byte transactions limitation #2208

darosior commented at 7:40 PM on July 7, 2026: member

Mention in the rationale section a recently proposed alternative to invalidating 64-byte transactions. Narrow the claim that invalidating 64-byte transactions fixes the vulnerability without requiring SPV verifiers to implement a workaround: it is possible to come up with esoteric constructions that would expect an SPV proof for 64-byte transactions and would need to be patched, so it can't be claimed generally.

jonatack added the label BIP Update by Owner on Jul 7, 2026

in bip-0054.md:110 in eacef5c4cf

 111 | -invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to
 112 | -rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes
 113 | -debate] for an attempt at summarizing the arguments for both sides of this debate.
 114 | +witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle
 115 | +tree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond
 116 | +to a valid serialization for a Bitcoin transaction[^14]. These options make some of the available

danielabrozzoni commented at 4:28 PM on July 8, 2026:

micro micro nit: you are spelling it "serialization" here, but "serialisation" in the footnote 13 below, so "serialisation" would be more consistent here.

(Codex caught this, I would have never noticed :))

darosior commented at 5:21 PM on July 8, 2026:

Heh, thanks for paying attention. Consistency to either American or British spelling is not a goal for this BIP, but it's also unnecessary to introduce one more inconsistency here. Changed to "serialisation".

danielabrozzoni commented at 4:36 PM on July 8, 2026: member

Looks good to me! I only left a mini nit, feel free to ignore

darosior force-pushed on Jul 8, 2026

in bip-0054.md:239 in 2467d7d4e6

 235 | @@ -236,6 +236,7 @@ valid serialisation of a Bitcoin transaction. More details about these are avail
 236 |  post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be
 237 |  provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
 238 |  MERKLEBLOCK] for a full description.
 239 | +[^14]: Proposed by Jeremy Rubin [here][Rubin node preimages].

murchandamus commented at 6:34 PM on July 8, 2026:

Similarly here:

[^14]: [Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions (mailing list)][Rubin node preimages].

Also, I think this link is the wrong one, it links to Antoine Riard’s email, I think you mean one higher up in the thread.

darosior commented at 6:59 PM on July 8, 2026:

Fixed both, thanks.

in bip-0054.md:108 in 2467d7d4e6 outdated

 109 | -tree depth in the header's version field[^8], which would make one workaround for a known
 110 | -vulnerability easier to deploy. The authors believe it is preferable to address the root cause by
 111 | -invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to
 112 | -rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes
 113 | -debate] for an attempt at summarizing the arguments for both sides of this debate.
 114 | +witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle

murchandamus commented at 6:35 PM on July 8, 2026:

I prefer when link texts give a bit more information about what is linked than "here". That link text could for example be "Delving Discussion" or "64-byte transaction discussion on Delving" or similar.

darosior commented at 6:56 PM on July 8, 2026:

So the sentence would be "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 (Delving Discussion)."? That reads weird to me.

darosior commented at 7:01 PM on July 8, 2026:

I prefer the current version, as i think it better suggests "here is some further discussions on this topic" without being too verbose.

murchandamus commented at 7:59 PM on July 8, 2026:

No worries, this is not a blocker.

murchandamus commented at 6:35 PM on July 8, 2026: member

Looks good to me. A couple optional nits.

darosior force-pushed on Jul 8, 2026

bip-0054: mention Jeremy's alternative proposal in rationale 9ec73fc6ed

bip-0054: an SPV verifier that supports 64-byte txs would have to be modified 7c7e2f10a4

darosior force-pushed on Jul 8, 2026

murchandamus merged this on Jul 8, 2026

murchandamus closed this on Jul 8, 2026

darosior deleted the branch on Jul 9, 2026