Skip to content

[pull] master from bitcoin:master #175

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

Merged
pull merged 3 commits into from
Jul 8, 2026
Merged

[pull] master from bitcoin:master #175

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9ec73fc
bip-0054: mention Jeremy's alternative proposal in rationale
darosior Jul 7, 2026
7c7e2f1
bip-0054: an SPV verifier that supports 64-byte txs would have to be …
darosior Jul 7, 2026
f3cf667
Merge pull request #2208 from darosior/2607_wording_64byte_txs
murchandamus Jul 8, 2026
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
14 changes: 8 additions & 6 deletions bip-0054.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
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.
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 serialisation 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. This fixes the vulnerability for users relying on Merkle proofs
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
unused in coinbase transactions. Using it to enforce that new coinbase transactions differ from
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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/
Loading