diff --git a/bip-0054.md b/bip-0054.md
index 3df8b441..0b856ab5 100644
--- a/bip-0054.md
+++ b/bip-0054.md
@@ -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
@@ -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