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: disambiguate use of "mitigation"

Browse Source 
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.
This commit is contained in:
Antoine Poinsot
2026-05-17 17:09:11 -04:00
parent 47a2d72539
commit 9e8e357b03
1 changed files with 9 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

17
bip-0054.md
View File

@@ -42,8 +42,9 @@ In computing a block's Merkle root, a transaction with exactly 64 bytes of non-w
interpreted both as an intermediate node in the tree and as a leaf in the tree. 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.
64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or
any other user of Merkle proofs, to rely on one of the available workarounds or even to know one is
necessary in the first place.
Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until
block height 1,983,702[^0]. Mandating new coinbase transactions be different from the early
@@ -108,12 +109,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 that the known vulnerabilities could
instead be mitigated by committing to the Merkle tree depth in the header's version field[^8]. 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.
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
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.
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