diff --git a/bip-0054.md b/bip-0054.md
index ab88f80d4c..bf5e6527c3 100644
--- a/bip-0054.md
+++ b/bip-0054.md
@@ -105,12 +105,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 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.
+witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle
+tree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond
+to a valid serialisation for a Bitcoin transaction[^14]. These options make some of the available
+workarounds[^13] easier to deploy. The authors believe it is preferable to address the root cause by
+invalidating 64-byte transactions. This fixes the vulnerability for users relying on Merkle proofs
+of non-64-byte transactions, without requiring a workaround.
 
 The `nLockTime` field of transactions is a natural place to store a block height and is currently
 unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from
@@ -236,6 +236,7 @@ valid serialisation of a Bitcoin transaction. More details about these are avail
 post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be
 provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
 MERKLEBLOCK] for a full description.
+[^14]: [Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list)][Rubin node preimages].
 
 [Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93
 [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
@@ -264,3 +265,4 @@ MERKLEBLOCK] for a full description.
 [Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459
 [miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
 [ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/
+[Rubin node preimages]: https://gnusha.org/pi/bitcoindev/f97afcc5-54ba-4284-8e9b-e8c35c7101f6n@googlegroups.com/