1
0
mirror of https://github.com/bitcoin/bips.git synced 2026-06-01 17:15:27 +00:00

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.
This commit is contained in:
Antoine Poinsot
2026-05-17 17:09:11 -04:00
parent 47a2d72539
commit 9e8e357b03

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 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 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 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 64-byte transactions addresses this vulnerability without requiring users of SPV verifiers, or
one of the available mitigations, or even to know one is necessary in the first place. 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 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 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 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 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 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 witness-stripped transaction sizes. Others have suggested instead committing to the Merkle
instead be mitigated by committing to the Merkle tree depth in the header's version field[^8]. The tree depth in the header's version field[^8], which would make one workaround for a known
authors believe it is preferable to address the root cause by invalidating 64-byte transactions, vulnerability easier to deploy. The authors believe it is preferable to address the root cause by
fixing the vulnerability without developers of SPV verifiers having to implement the mitigation or invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to
to know it is necessary in the first place. See [this post][64 bytes debate] for an attempt at rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes
summarizing the arguments for both sides of this debate. 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 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