bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-12-22 14:45:19 +00:00
Code Issues Releases Wiki Activity

Merge pull request #2034 from hodlinator/2025/11/bip53/inversion_typo

Browse Source
This commit is contained in:
Jon Atack 2025-12-09 08:30:36 -08:00 committed by GitHub
commit 7635df6fd3
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bip-0053.mediawiki
View File

@ -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 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. 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>. 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(T<sub>0</sub>||T<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 T<sub>0</sub>||T<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 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 ==== ==== Block malleability with consensus INVALID transactions ====
@ -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 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 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 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== ==Rationale==