bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-07-13 17:56:00 +00:00
Code Issues Releases Wiki Activity

Merge pull request #2208 from darosior/2607_wording_64byte_txs

Browse Source 
BIP 54: mention recent ML discussion and 64-byte transactions limitation
This commit is contained in:
Murch
2026-07-08 13:00:08 -07:00
committed by GitHub
parent f078d4f5ff 7c7e2f10a4
commit f3cf667c3e
1 changed files with 8 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
bip-0054.md
View File

@@ -105,12 +105,12 @@ invalid[^7].
burns them. They have also been non-standard since 2019 and never been used since 2016. Several burns them. They have also been non-standard since 2019 and never been used since 2016. Several
alternatives to invalidating them were previously proposed. Some believe the improvements for users alternatives to invalidating them were previously proposed. Some believe the improvements for users
of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid of Merkle proofs are too marginal to be worth introducing a discontinuity in the set of valid
witness-stripped transaction sizes. Others have suggested instead committing to the Merkle witness-stripped transaction sizes (discussion [here][64 bytes debate]). Others have suggested instead committing to the Merkle
tree depth in the header's version field[^8], which would make one workaround for a known tree depth in the header's version field[^8], or even invalidating Merkle tree nodes that correspond
vulnerability easier to deploy. The authors believe it is preferable to address the root cause by to a valid serialisation for a Bitcoin transaction[^14]. These options make some of the available
invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to workarounds[^13] easier to deploy. The authors believe it is preferable to address the root cause by
rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes invalidating 64-byte transactions. This fixes the vulnerability for users relying on Merkle proofs
debate] for an attempt at summarizing the arguments for both sides of this debate. of non-64-byte transactions, without requiring a workaround.
The `nLockTime` field of transactions is a natural place to store a block height and is currently The `nLockTime` field of transactions is a natural place to store a block height and is currently
unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from
@@ -236,6 +236,7 @@ valid serialisation of a Bitcoin transaction. More details about these are avail
post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be post]. A third workaround is to change the Merkle proof structure by requiring inner nodes to be
provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
MERKLEBLOCK] for a full description. MERKLEBLOCK] for a full description.
[^14]: [Jeremy Rubin "Prohibit Merkle Internal Node Preimages That Encode Minimal 64-Byte Transactions" (mailing list)][Rubin node preimages].
[Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93 [Delving worst block]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/93
[BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki [BIP30]: https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
@@ -264,3 +265,4 @@ MERKLEBLOCK] for a full description.
[Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459 [Core validation.cpp BIP34]: https://github.com/bitcoin/bitcoin/blob/390e7d61bd531505bb3d13f38316c282b85ed1dd/src/validation.cpp#L2401-L2459
[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk [miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
[ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/ [ML remaining concerns]: https://gnusha.org/pi/bitcoindev/UsKuvCXXhSAnNVx5a0K2UfP3srAr3slW9mcOjtYk9LnolaOXfWrW9jpqbxsQQPkyQuZogkhz2Hbfwii2VsTm79vRDpgKduxk35hpBu_t7Do=@protonmail.com/
[Rubin node preimages]: https://gnusha.org/pi/bitcoindev/f97afcc5-54ba-4284-8e9b-e8c35c7101f6n@googlegroups.com/