bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-06-01 17:15:27 +00:00
Code Issues Releases Wiki Activity

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

Browse Source 
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,
This commit is contained in:
Antoine Poinsot
2026-05-14 09:04:36 -04:00
parent 346f93844f
commit 5c67f90fa8
1 changed files with 16 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
bip-0054.md
View File

@@ -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 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 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 interpreted either as a transaction or as the concatenation of two 32-byte hashes. Reinterpreting a
it such that for a valid block the Merkle root in the block header is not a unique identifier for transaction as a node allows creating a valid Merkle proof for a transaction not included in a
the corresponding list of valid transactions[^8]. 64-byte transactions can only contain a block. 64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one
scriptPubKey that lets anyone spend the funds, or one that burns them. 64-byte transactions have that burns them. 64-byte transactions have also been non-standard since 2019 and unused since 2016.
also been non-standard since 2019. It was suggested that the known vulnerabilities could instead be It was suggested that the known vulnerabilities could instead be mitigated by committing to the
mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors 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. This believe it is preferable to address the root cause by invalidating 64-byte transactions, fixing the
approach also fixes the vulnerability without developers of SPV verifiers having to implement the vulnerability without developers of SPV verifiers having to implement the mitigation or to know it
mitigation or to know it is necessary in the first place. 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 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 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 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 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. 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 [^8]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric
of the consequences. version].
[^9]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric [^9]: Bitcoin Core versions between 0.13.0 and 0.13.2 implemented caching that made it vulnerable to
version]. Eric also pushed back against the importance of fixing this issue. See [this post][64 this attack. See [this writeup][Suhas Merkle] by Suhas Daftuar for a detailed explanation.
bytes debate] for an attempt at summarizing the arguments for both sides of this debate.
[^10]: See [here][BIP34 list] for a full list of the heights of historical blocks including a valid [^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. 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 [^11]: Technically it could be argued a duplicate could in principle always be possible before block