BIP53: Clarify implementation complexity and improve tx notation

hodlinator commented at 9:38 pm on November 10, 2025: contributor

1st commit: The existing wording on master could be taken to mean that 64-byte transactions reduce implementation complexity for SPV wallets.
2nd commit: Uses distinct notation for txids and tx-bytes.

hodlinator renamed this:
~~BIP53: Fix inversion~~
BIP53: Typo - fix inversion
on Nov 10, 2025

murchandamus commented at 10:29 pm on November 12, 2025: contributor

cc: @Christewart

murchandamus added the label Proposed BIP modification on Nov 12, 2025

murchandamus added the label Pending acceptance on Nov 12, 2025

fananinafisa-blip commented at 5:10 am on November 19, 2025: none

Claim

BIP53: Clarify wording around implementation complexity

Co-authored-by: Chris Stewart <stewart.chris1234@gmail.com>

cbaedf2dfc

in bip-0053.mediawiki:87 in 0798f68aee

83@@ -84,7 +84,7 @@ are less constrained than the first 32 bytes) are constructed so that they colli
84 with the hash of some other fake, invalid transaction F. The attacker can fool the SPV client into believing that F
85 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
86 construct the funding transaction whose coins will be spent by this one) is able
87-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>.
88+to fool an SPV client in this way.]]</ref> of work. This also increases 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>.

Christewart commented at 8:59 pm on November 25, 2025:

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.

hodlinator commented at 10:01 am on November 27, 2025:

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

hodlinator force-pushed on Nov 27, 2025

hodlinator renamed this:
~~BIP53: Typo - fix inversion~~
BIP53: Clarify wording around implementation complexity
on Nov 27, 2025

BIP53: Use different notation for txids and tx-bytes c569e23641

in bip-0053.mediawiki:45 in cbaedf2dfc

hodlinator commented at 10:48 am on November 27, 2025:

(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:

Grind valid transactions for Txid0 and Txid1 to make them deserialize successfully as Tm.
Probably need to collude with a miner/pool to make sure the 2 valid transactions become siblings.

It’s also confusing to use T0 to denote a transaction id and Tm to denote the bytes of a transaction.

Suggested change of notation:

 0@@ -38,11 +38,11 @@ This has been mitigated by Bitcoin Core's relay policy and the RPC interface sin
 1 64-byte transactions introduce block malleability. Malicious peers can construct consensus valid and invalid 64-byte
 2 transactions that have the same serialization as the concatenation of 2 hashes in the Merkle tree.
 3 
 4-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>.
 5-The Merkle root for this block is H(T<sub>0</sub>||T<sub>1</sub>).
 6-A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to T<sub>0</sub>||T<sub>1</sub>.
 7+Assume we have a valid Bitcoin block with 2 transactions in it with Txid<sub>0</sub> and Txid<sub>1</sub>.
 8+The Merkle root for this block is H(Txid<sub>0</sub>||Txid<sub>1</sub>).
 9+A malicious user could find a 64-byte transaction T<sub>m</sub> that serializes to Txid<sub>0</sub>||Txid<sub>1</sub>.
10 Next that user relays the block containing the malicious T<sub>m</sub> rather than the
11-valid Bitcoin transactions that correspond with T<sub>0</sub> and T<sub>1</sub>.
12+valid Bitcoin transactions that correspond with Txid<sub>0</sub> and Txid<sub>1</sub>.
13 
14 ==== Block malleability with consensus INVALID transactions ====
15

Still leaves T0 notation in “Other peers on the network receive the valid block containing T0 and T1” 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.

Christewart commented at 7:41 pm on November 27, 2025:

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.

jonatack commented at 7:57 pm on November 27, 2025:

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)

hodlinator commented at 8:07 pm on November 27, 2025:

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

hodlinator renamed this:
~~BIP53: Clarify wording around implementation complexity~~
BIP53: Clarify implementation complexity and improve tx notation
on Nov 27, 2025

rkrux commented at 11:25 am on December 1, 2025: contributor

lgtm ACK c569e23641e6899c48e804a65f7c6cb15d9705f3

Improves the wording in the BIP, reducing the scope of confusion that could potentially arise.

murchandamus commented at 6:33 pm on December 8, 2025: contributor

ACK c569e23641e6899c48e804a65f7c6cb15d9705f3, changes look good to me. @Christewart, could you please read the latest verstion and ACK the commit, if this seems right to you?

Christewart commented at 4:26 pm on December 9, 2025: contributor

ACK https://github.com/bitcoin/bips/commit/c569e23641e6899c48e804a65f7c6cb15d9705f3

jonatack merged this on Dec 9, 2025

jonatack closed this on Dec 9, 2025

jonatack removed the label Pending acceptance on Dec 9, 2025

BIP53: Clarify implementation complexity and improve tx notation #2034