BIP 54: clarify 64-byte transactions item description and rationale

bip-0054.md

@@ -38,10 +38,10 @@ users, increasing the cost to independently fully validate the consensus rules.
 be used by miners to attack their competition, creating perverse incentives, centralization
 pressures and leading to reduced network security.
 
-In computing a block's Merkle root, a 64-byte transaction can be interpreted both as an intermediate
-node in the tree and as a leaf in the tree. This makes it possible to fake inclusion proofs by
-pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on
-one level of the tree are the actual block transactions.
+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 fake inclusion proofs by pretending a 64-byte block transaction is an inner node, as
+well as to pretend the inner nodes on one level of the tree are the actual block transactions.
 
 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
@@ -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
 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
-it such that for a valid block the Merkle root in the block header is not a unique identifier for
-the corresponding list of valid transactions[^8]. 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. It was suggested that the known vulnerabilities could instead be
-mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors
-believe it is preferable to address the root cause by invalidating 64-byte transactions. This
-approach also fixes the vulnerability without developers of SPV verifiers having to implement the
-mitigation or to know it is necessary in the first place.
+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.
 
 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
@@ -146,7 +149,7 @@ Bitcoin Core version [30.0][Core 30.0] and later will not generate a block templ
 transaction that violates the signature operations limit introduced in this BIP.
 
 Bitcoin Core version [0.16.1][Core 0.16.1] and later will neither relay nor create block templates
-that include 64-byte transactions.
+that include transactions whose witness-stripped serialized size is exactly 64 bytes.
 
 The coinbase transaction is usually crafted by mining pool software. To the best of the authors'
 knowledge, there does not exist an open source reference broadly in use today for such software.
@@ -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
 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]: See [this writeup][Suhas Merkle] by Suhas Daftuar for an explanation as well as a discussion
-of the consequences.
-[^9]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric
-version]. Eric also pushed back against the importance of fixing this issue. See [this post][64
-bytes debate] for an attempt at summarizing the arguments for both sides of this debate.
+[^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.
 [^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