BIP53: Clarify implementation complexity and improve tx notation #2034

Hi @hodlinator

Thanks for taking a look at this.

I believe this is correct as is. Take a look at the foot note. I admit this could probably be worded better - something like

Disallowing 64-byte transactions reduces the implementation complexity for SPV wallets.

Perhaps the foot note wording could be improved as well

The steps needed to make sure a Merkle proof for a 64-byte transaction is secure.

Adding more context makes it clearer, thanks @Christewart! Suggestions taken in latest push, without modifications.

(Sorry for deleting previous comment + reposting, trying to present my ideas better).

There may still be potential to spell things out a bit better? It was not immediately obvious to me that the attacker would:

1. Grind valid transactions for Txid₀ and Txid₁ to make them deserialize successfully as T_m.
2. Probably need to collude with a miner/pool to make sure the 2 valid transactions become siblings.

It's also confusing to use T₀ to denote a transaction id and T_m to denote the bytes of a transaction.

Suggested change of notation:

@@ -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 with Txid<sub>0</sub> and Txid<sub>1</sub>.
 
 ==== Block malleability with consensus INVALID transactions ====
 

Still leaves T<sub>0 notation in "Other peers on the network receive the valid block containing T₀ and T₁" further down.

Edit: Not sure why GitHub refuses to render the suggestion diff correctly, maybe HTML code (reverted back to use diff-block instead of suggestion-block).

The paper in /bip-0053/2-BitcoinMerkle.pdf helped deepen my understanding.

The diff seems reasonable to me if you want to add it to this piece work.

Agree the paper is good at laying this out.

nit in proposed text: s/correspond with/correspond to/

(use "correspond with" for communication with, and "correspond to" for when two things are similar, match, or are in agreement)

Pushed second commit containing the notation change and correspond-typo.