From 9e8e357b0388d532e277e03b0bf372b39fedcc44 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 17 May 2026 17:09:11 -0400 Subject: [PATCH] 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. --- bip-0054.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/bip-0054.md b/bip-0054.md index 2ac74c8d..3f6dcd95 100644 --- a/bip-0054.md +++ b/bip-0054.md @@ -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