From 5c67f90fa81cdf4ab4a955b2a11f54a4727fef88 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Thu, 14 May 2026 09:04:36 -0400 Subject: [PATCH] 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, --- bip-0054.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index 3df8b441..0b856ab5 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -104,15 +104,18 @@ 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. The former allows faking a block inclusion proof and the latter makes -it such that for a valid block the Merkle root in the block header is not a unique identifier for -the corresponding list of valid transactions[^8]. 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. It was suggested that the known vulnerabilities could instead be -mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors -believe it is preferable to address the root cause by invalidating 64-byte transactions. This -approach also fixes the vulnerability without developers of SPV verifiers having to implement the -mitigation or to know it is necessary in the first place. +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. 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 @@ -207,11 +210,10 @@ 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]: See [this writeup][Suhas Merkle] by Suhas Daftuar for an explanation as well as a discussion -of the consequences. -[^9]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric -version]. Eric also pushed back against the importance of fixing this issue. See [this post][64 -bytes debate] for an attempt at summarizing the arguments for both sides of this debate. +[^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. [^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