Skip to content

BIP53: Clarify implementation complexity and improve tx notation #2034

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
+5 −5
Open

BIP53: Clarify implementation complexity and improve tx notation #2034

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
cbaedf2
BIP53: Clarify wording around implementation complexity
hodlinator Nov 26, 2025
c569e23
BIP53: Use different notation for txids and tx-bytes
hodlinator Nov 27, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions bip-0053.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 ====

Expand Down Expand Up @@ -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==

Expand Down