From cbaedf2dfc1f4a0104d934a3f2121f911d39f2bb Mon Sep 17 00:00:00 2001
From: Hodlinator <172445034+hodlinator@users.noreply.github.com>
Date: Wed, 26 Nov 2025 17:30:11 +0100
Subject: [PATCH 1/2] BIP53: Clarify wording around implementation complexity

Co-authored-by: Chris Stewart <stewart.chris1234@gmail.com>
---
 bip-0053.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0053.mediawiki b/bip-0053.mediawiki
index 60d3996c..b2dd9c81 100644
--- a/bip-0053.mediawiki
+++ b/bip-0053.mediawiki
@@ -84,7 +84,7 @@ are less constrained than the first 32 bytes) are constructed so that they colli
 with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
 was included in a Bitcoin block rather than T with 81 bits<ref>[[bip-0053/2-BitcoinMerkle.pdf|An attacker who can do 81 bits of work (followed by another 40 bits of work, to
 construct the funding transaction whose coins will be spent by this one) is able
-to fool an SPV client in this way.]]</ref> of work. This also reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a transaction is secure.]</ref>.
+to fool an SPV client in this way.]]</ref> of work. Disallowing 64-byte transactions reduces implementation complexity for SPV wallets<ref>[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/43 The steps needed to make sure a Merkle proof for a 64-byte transaction is secure.]</ref>.
 
 ==Rationale==
 

From c569e23641e6899c48e804a65f7c6cb15d9705f3 Mon Sep 17 00:00:00 2001
From: Hodlinator <172445034+hodlinator@users.noreply.github.com>
Date: Thu, 27 Nov 2025 21:03:42 +0100
Subject: [PATCH 2/2] BIP53: Use different notation for txids and tx-bytes

---
 bip-0053.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0053.mediawiki b/bip-0053.mediawiki
index b2dd9c81..ccc3f2fd 100644
--- a/bip-0053.mediawiki
+++ b/bip-0053.mediawiki
@@ -38,11 +38,11 @@ This has been mitigated by Bitcoin Core's relay policy and the RPC interface sin
 64-byte transactions introduce block malleability. Malicious peers can construct consensus valid and invalid 64-byte
 transactions that have the same serialization as the concatenation of 2 hashes in the Merkle tree.
 
-Assume we have a valid Bitcoin block with 2 transactions in it that have transaction ids of T<sub>0</sub> and T<sub>1</sub>.
-The Merkle root for this block is H(T<sub>0</sub>||T<sub>1</sub>).
-A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to T<sub>0</sub>||T<sub>1</sub>.
+Assume we have a valid Bitcoin block with 2 transactions in it with Txid<sub>0</sub> and Txid<sub>1</sub>.
+The Merkle root for this block is H(Txid<sub>0</sub>||Txid<sub>1</sub>).
+A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to Txid<sub>0</sub>||Txid<sub>1</sub>.
 Next that user relays the block containing the malicious T<sub>m</sub> rather than the
-valid Bitcoin transactions that correspond with T<sub>0</sub> and T<sub>1</sub>.
+valid Bitcoin transactions that correspond to Txid<sub>0</sub> and Txid<sub>1</sub>.
 
 ==== Block malleability with consensus INVALID transactions ====