BIP 54: clarify 64-byte transactions item description and rationale #2159

darosior commented at 1:27 PM on May 14, 2026: member

A recent ML post pointed that not repeating across the BIP how the witness-stripped serialized size is considered for 64-byte transactions invalidation was confusing to some people. This makes the text a bit heavier, but in this PR we change two places to spell it out explicitly, in addition to the preexisting specifications section. Another modification was requested in the ML post, which i believe is incorrect and have responded to there.

A response on that same ML thread requested the rationale section to be clearer as to the motivation for invalidating 64-byte transactions. In particular, the point that it introduces a "seam" that may be surprising should be discussed and addressed in the main section instead of a footnote. Also, it should be clarified that full node consensus failure cannot be the main motivation for invalidating 64-byte transactions since it is better addressed alternatively. Both are done in the second commit of this PR.

bip-0054: spell out in more places that 64 bytes is for witness-stripped size 346f93844f

bip-0054: clarify rationale for invalidating 64-byte txs

As Eric points out on the mailing list: 1. the rationale section should mention and address the
"seam" objection directly rather than burying it in a footnote; 2. the full node consensus split
issue should not be used as sole rationale for invalidating 64-byte txs (but it's fair to point out
it's fixed as a nice to have byproduct).

ML thread: https://gnusha.org/pi/bitcoindev/43996cb3-9133-4627-8944-5fe08427be68n@googlegroups.com/T/#md66e252f0748f4ef7569d5e15d42631e12b66c0b,

5c67f90fa8

jonatack added the label BIP Update by Owner on May 14, 2026

in bip-0054.md:105 in 346f93844f

jonatack commented at 9:02 PM on May 14, 2026:

Commit 346f93844f9b7dc1df184edd7383f5cca5e0c02e ACK, should the extra precision be added at the top of this paragraph too?

darosior commented at 1:32 PM on May 15, 2026:

I think that's too much to repeat it in every single sentence. I also looked into defining it once at the top, but that wasn't a great result either. I think it's fine as is: it is spelled out in the first occurrence, in the specs, and in a paragraph where it may not be directly obvious. In this paragraph you comment on, it should be obvious to anyone with some technical understanding of Bitcoin, since the block header's Merkle root by definition does not consider the segregated witness.

darosior commented at 3:21 PM on May 15, 2026:

Turns out that in my rewrite, spelling it out in the rationale didn't seem too heavy, so i just did it there as well.

jonatack commented at 9:08 PM on May 14, 2026: member

LGTM. Perhaps @JeremyRubin or @evoskuil could take a look?

in bip-0054.md:44 in 5c67f90fa8

  43 | -pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on
  44 | -one level of the tree are the actual block transactions.
  45 | +In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be
  46 | +interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it
  47 | +possible to fake inclusion proofs by pretending a 64-byte block transaction is an inner node, as
  48 | +well as to pretend the inner nodes on one level of the tree are the actual block transactions.

evoskuil commented at 12:58 AM on May 15, 2026:

I think it's worth being explicit here that it's not possible for a block to pass validation with a malleated merkle root. Also I think it's worth showing specifically the current approach that this fork replaces (suggestion in italics):

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. While it is not possible for a malleated block to pass validation, this does makes it possible for an SPV server to fake inclusion proofs by pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on one level of the tree are the actual block transactions. Presently this must be guarded by obtaining the coinbase tx (e.g. with the header), verifying its inclusion, and that it starts with a null point.

darosior commented at 1:52 PM on May 15, 2026:

There are multiple mitigations currently available, i don't think we should discuss those in the rationale. For instance it seems that the BitVM people went for another mitigation.

Regarding passing validation, let me see if i can make it clearer that it only affects SPV verifiers.

darosior commented at 3:17 PM on May 15, 2026:

I spelled out this is an issue only for SPV verifiers in the commit i just added.

in bip-0054.md:112 in 5c67f90fa8

 116 | +interpreted either as a transaction or as the concatenation of two 32-byte hashes. Reinterpreting a
 117 | +transaction as a node allows creating a valid Merkle proof for a transaction not included in a
 118 | +block. 64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one
 119 | +that burns them. 64-byte transactions have also been non-standard since 2019 and unused since 2016.
 120 | +It was suggested that the known vulnerabilities could instead be mitigated by committing to the
 121 | +Merkle tree depth in the header's version field[^8], to avoid introducing a "seam". The authors

evoskuil commented at 1:13 AM on May 15, 2026:

This implies the only viable alterative is the above suggestion (which was not mine). I suggested (which is not included anywhere in the discussion here) that mitigation may not be necessary given that:

A block that is validated could not have been malleated.
On nodes malleation only affects certain caching optimizations.
Mitigation of (2) is no more costly than implementing this rule.
On SPV wallets malleation affects inclusion proofs.
Mitigation of (4) marginally complicates SPV clients.
Eliminating (5) may or may not be worth the costs of adding a consensus rule.

darosior commented at 1:57 PM on May 15, 2026:

Ok, i didn't mean to imply this is the only viable alternative. I'll update to mention that another alternative is to keep relying on existing mitigations instead.

darosior commented at 3:20 PM on May 15, 2026:

This is now explicitly discussed in the rationale. There are alternative consensus changes possible, and, of course, one alternative is always to not change anything. I mentioned that some argued for the latter on the ground that the discontinuity ("seam") this introduced was not worth it, largely taking from your posts starting here but without linking any specific one (since for instance you retracted part of this one i link here), but keeping the link to my later comments attempting to summarize each side's arguments. People can then scroll up a couple messages to read the original.

in bip-0054.md:118 in 5c67f90fa8

 122 | +believe it is preferable to address the root cause by invalidating 64-byte transactions, fixing the
 123 | +vulnerability without developers of SPV verifiers having to implement the mitigation or to know it
 124 | +is necessary in the first place. See [this post][64 bytes debate] for an attempt at summarizing the
 125 | +arguments for both sides of this debate. Reinterpreting Merkle tree nodes as transactions could be
 126 | +used to cause a vulnerable node to fall out of consensus[^9]. There are better ways to mitigate this
 127 | +issue on its own, but it is also addressed as a byproduct of invalidating 64-byte transactions.

evoskuil commented at 1:26 AM on May 15, 2026:

There are better ways to mitigate this issue on its own

This hints at (1,2,3) above, but this isn't very clear. A "vulnerable node" is one that has implemented caching without considering malleation.

So what this says is that, with this rule, SPV wallets don't require the mitigation, which has a marginal runtime benefit, and as a byproduct nodes implement this rule instead of the mitigation. It's also worth pointing out that the caching node mitigations are to ensure:

first tx in block starts with a null point
there are no duplicate txs in the block

(1) is an immediate exit on block parse, as these are the first bytes after the header, and (2) is straightforward. And of course neither of these are possible with simple static validation (check) of the block.

All of the above was discussed in detail with examples, etc. on bitcoin dev. To provide more clarity it might be worth including that reference.

evoskuil commented at 2:37 AM on May 15, 2026:

IIRC number (2) above is a different aspect of malleability not mitigated by this proposal, so that node guard would remain in any case.

darosior commented at 3:21 PM on May 15, 2026:

I moved that entirely to a footnote linked from the motivation, mentioning it since it is related, but stating it is largely orthogonal to invalidating 64-byte transactions.

bip-0054: state explicitly fake inclusion proofs only concern SPV verifier 8ae3af58e0

bip-0054: less redundancy in 64-byte rationale, move caching risk to footnote 72d8275a97

darosior commented at 3:16 PM on May 15, 2026: member

Alright, i went further into rewriting the rationale. I removed the description of the source of malleability (inner node / leaf node) since it is already discussed in the motivation. I focused on discussing arguments in favour of the invalidation, and objections / alternatives. I relegated the discussion of the caching consensus bug to a footnote, since really it is largely orthogonal to this proposal.

evoskuil commented at 5:31 PM on May 15, 2026: contributor

Since this rule is about reducing the complexity of SPV verification, the motivation should detail what that is. Presently its only described as a marginal reduction in complexity that requires a mitigation. Reading this fresh my first question would be, what specifically is the complexity/mitigation that this new rule will eliminate. I provided that high level description in the resolved comments above. How else can people weigh the tradeoff being proposed: new consensus rule or existing mitigation. I'm not taking a position on that question, but that is the question and should be presented clearly.

darosior commented at 5:44 PM on May 15, 2026: member

I think really the issue is that SPV verifiers need to know a mitigation is necessary in the first place. Invalidating 64-byte transactions remove this footgun at the protocol level, so that applications do not have to care / know about it. This is what is stated in the motivation:

[..] 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[^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.

evoskuil commented at 5:47 PM on May 15, 2026: contributor

That's fine, but it's an opinion on a tradeoff. The actual mitigation that is being replaced should be described with sufficient detail for people to make an informed decision. One could also raise the real possibility that a specific size transaction being invalid is also a footgun, as transaction creation (and validation) must avoid it.

darosior commented at 5:55 PM on May 15, 2026: member

I know of at least three mitigations: request an additional Merkle proof for the coinbase transaction and compare depths, reject proofs with inner nodes that deserialize to a Bitcoin transaction, and use modified Merkle proofs (request the preimage of the second SHA256, instead of the result of the double-SHA256). Each have their own tradeoffs, but they all have one thing in common: they are hacks to get around the root cause that the existence of 64-byte transactions make regular Merkle proofs insecure and implementers have to know about it.

darosior commented at 5:58 PM on May 15, 2026: member

Also, this is not an opinion on a tradeoff. This is a fact: invalidating 64-byte transactions removes the need to know that a mitigation is necessary, and the cost of implementing it.

evoskuil commented at 6:01 PM on May 15, 2026: contributor

I know of at least three mitigations...

There is no harm in presenting all three, and any others. I chose a simple one that requires no change to existing server behaviors (which is therefore presumably already in use).

I think really the issue is that SPV verifiers need to know a mitigation is necessary in the first place.

This is an opinion. The objective here is to lay out the option, not to impose a preference or to lead people to it. Others may believe that the issue here is the imposition of a new consensus rule, with its own costs, in order to simplify SPV implementation.

jonatack commented at 7:38 PM on May 15, 2026: member

Re-reading, I'll admit to being initially confused if the word "mitigation," as used in this BIP, is referring to the same thing throughout (fixes proposed by the BIP), and where not, propose using a different term (or vice versa).

in bip-0054.md:46 in 72d8275a97

  45 | +In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be
  46 | +interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it
  47 | +possible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not
  48 | +part of a block, by pretending a 64-byte block transaction is actually an inner node[^9]. Invalidating
  49 | +64-byte transactions addresses this vulnerability without requiring users of SPV verifiers to deploy
  50 | +one of the available mitigations, or even to know one is necessary in the first place.

jonatack commented at 7:41 PM on May 15, 2026:

Might be helpful to link to a footnote or URL that describes the "available mitigations" (if I'm not confused, I may well be) and consider using a different term here than in the test vectors and acknowledgements sections, if they are referring to different things as they seem to be.

darosior commented at 9:44 PM on May 17, 2026:

Indeed, this was confusing. I added a commit to rephrase this.

bip-0054: disambiguate use of "mitigation"

Jon pointed that i use "mitigation" to refer both to the items of this
BIP, and for the existing workarounds to make SPV verifiers safe in the
presence of 64-byte txs. This commit rephrases the latter usage.

4307039dc2

bip-0054: add a footnote with known workarounds for SPV verifiers a4c6fd5bfe

in bip-0054.md:114 in 72d8275a97

 120 | +alternatives to invalidating them were previously proposed. Some believe the discontinuity it
 121 | +introduces in the set of valid witness-stripped transaction sizes is not worth the marginal
 122 | +reduction in complexity to SPV verifiers. Others have suggested that the known vulnerabilities could
 123 | +instead be mitigated by committing to the Merkle tree depth in the header's version field[^8]. The
 124 | +authors believe it is preferable to address the root cause by invalidating 64-byte transactions,
 125 | +fixing the vulnerability without developers of SPV verifiers having to implement the mitigation or

jonatack commented at 7:42 PM on May 15, 2026:

Idem here as https://github.com/bitcoin/bips/pull/2159/changes#r3250592381.

darosior commented at 9:44 PM on May 17, 2026:

ditto #2159 (review)

darosior commented at 9:45 PM on May 17, 2026: member

Rephrased my use of mitigation for the currently available SPV verifier workarounds, and added a footnote that lists all three along with a link to a detailed discussion for each.

in bip-0054.md:112 in a4c6fd5bfe

 118 | -mitigation or to know it is necessary in the first place.
 119 | +64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that
 120 | +burns them. They have also been non-standard since 2019 and never been used since 2016.  Several
 121 | +alternatives to invalidating them were previously proposed. Some believe the discontinuity it
 122 | +introduces in the set of valid witness-stripped transaction sizes is not worth the marginal
 123 | +reduction in complexity to SPV verifiers. Others have suggested instead committing to the Merkle

jonatack commented at 9:27 PM on May 18, 2026:

In the sentence structure here of "A is not worth B," it seems that inverting A and B would be clearer.

Also maybe:

reduction in complexity for SPV verifiers. Others have suggested instead committing to the Merkle

in bip-0054.md:236 in a4c6fd5bfe

 227 | @@ -223,6 +228,13 @@ notably of Bitcoin Core but also of all other implementations the authors are aw
 228 |  where [bip-0034][BIP34] violations have been manually inspected (see [here][Core validation.cpp
 229 |  BIP34]). Without the guarantee given by enforcing the timelock on coinbase transactions, this would
 230 |  have to be perpetuated for the Consensus Cleanup.
 231 | +[^13]: The authors are aware of three workarounds for SPV verifiers. The first is to request a
 232 | +Merkle proof for the coinbase transaction in addition to the transaction of interest, to infer the
 233 | +depth of the Merkle tree. The second is to reject Merkle proofs in which any inner node is also a
 234 | +valid serialisation of a Bitcoin transaction. More details about these are available [here][Sergio
 235 | +post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be
 236 | +provided as the single SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio

jonatack commented at 9:27 PM on May 18, 2026:

nit, use the hyphen in the same way for "single SHA256" and "double-SHA256"

in bip-0054.md:253 in a4c6fd5bfe

 249 | @@ -238,7 +250,7 @@ have to be perpetuated for the Consensus Cleanup.
 250 |  [ML thread validation time]: https://gnusha.org/pi/bitcoindev/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com
 251 |  [Suhas Merkle]: https://gnusha.org/pi/bitcoindev/CAFp6fsGtEm9p-ZQF_XqfqyQGzZK7BS2SNp2z680QBsJiFDraEA@mail.gmail.com
 252 |  [Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design
 253 | -[Eric version]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/37
 254 | +[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/

jonatack commented at 9:28 PM on May 18, 2026:

Thank you for describing the workarounds and linking to this.

jonatack commented at 9:30 PM on May 18, 2026: member

Thank you @darosior for iterating on this; it looks better and better.