bip-0054: less redundancy in 64-byte rationale, move caching risk to footnote

bip-0054.md

@@ -41,7 +41,7 @@ pressures and leading to reduced network security.
 In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be
 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. 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
 one of the available mitigations, or even to know one is necessary in the first place.
 
@@ -104,20 +104,16 @@ increases the preparation cost of an attack, making it uneconomical for a miner[
 2500 was chosen as the tightest value that did not make any non-pathological standard transaction
 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. 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.
+64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that
+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.
 
 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
@@ -212,10 +208,14 @@ 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]: 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.
+[^8]: By Sergio Demian Lerner in a [blog post][Sergio post].
+[^9]: Conversely, pretending that the inner nodes on one level of the tree are the actual block
+transactions is another source of complexity for full node implementations, which previously
+resulted in consensus bugs. For instance, 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. Invalidating 64-byte transactions may avoid this risk, but
+the issue is largely orthogonal to this proposal: it is fundamentally about caching validation
+status for malleable blocks.
 [^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
@@ -242,7 +242,6 @@ have to be perpetuated for the Consensus Cleanup.
 [ML thread validation time]: https://gnusha.org/pi/bitcoindev/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com
 [Suhas Merkle]: https://gnusha.org/pi/bitcoindev/CAFp6fsGtEm9p-ZQF_XqfqyQGzZK7BS2SNp2z680QBsJiFDraEA@mail.gmail.com
 [Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design
-[Eric version]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/37
 [64 bytes debate]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
 [BIP34 list]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4
 [Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core