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

bip-0054: mention Jeremy's alternative proposal in rationale

Browse Source
This commit is contained in:
Antoine Poinsot
2026-07-07 14:57:40 -04:00
parent f078d4f5ff
commit 9ec73fc6ed
1 changed files with 7 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
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
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
witness-stripped transaction sizes. 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
vulnerability easier to deploy. The authors believe it is preferable to address the root cause by
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], or even invalidating Merkle tree nodes that correspond
to a valid serialization for a Bitcoin transaction[^14]. These options make some of the available
workarounds[^13] easier to deploy. The authors believe it is preferable to address the root cause by
invalidating 64-byte transactions, fixing the vulnerability without Merkle proof users having to
rely on any workaround or even know one is necessary in the first place. See [this post][64 bytes
debate] for an attempt at summarizing the arguments for both sides of this debate.
rely on any workaround or even know one is necessary in the first place.
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
@@ -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
provided as the single-SHA256 of their preimage, instead of the double-SHA256. See [here][Sergio
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
[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
[miningdev nLockTime]: https://groups.google.com/g/bitcoinminingdev/c/jlqlNHHNSNk
[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/