Skip to content

BIP 54: clarify 64-byte transactions item description and rationale #2159

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
darosior wants to merge 4 commits into
base: master
Choose a base branch
from
+25 −22
Open

BIP 54: clarify 64-byte transactions item description and rationale #2159

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
346f938
bip-0054: spell out in more places that 64 bytes is for witness-strip…
darosior May 12, 2026
5c67f90
bip-0054: clarify rationale for invalidating 64-byte txs
darosior May 14, 2026
8ae3af5
bip-0054: state explicitly fake inclusion proofs only concern SPV ver…
darosior May 15, 2026
72d8275
bip-0054: less redundancy in 64-byte rationale, move caching risk to …
darosior May 15, 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
47 changes: 25 additions & 22 deletions bip-0054.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,10 +38,12 @@ users, increasing the cost to independently fully validate the consensus rules.
be used by miners to attack their competition, creating perverse incentives, centralization
pressures and leading to reduced network security.

In computing a block's Merkle root, a 64-byte transaction can be interpreted both as an intermediate
node in the tree and as a leaf in the tree. This makes it possible to fake inclusion proofs by
pretending a 64-byte block transaction is an inner node, as well as to pretend the inner nodes on
one level of the tree are the actual block transactions.
In computing a block's Merkle root, a transaction with exactly 64 bytes of non-witness data can be
interpreted both as an intermediate node in the tree and as a leaf in the tree. This makes it
possible to trick an SPV verifier into accepting an inclusion proof for a transaction that is not
part of a block, by pretending a 64-byte block transaction is actually an inner node[^9]. Invalidating
64-byte transactions addresses this vulnerability without requiring users of SPV verifiers to deploy
one of the available mitigations, or even to know one is necessary in the first place.
Copy link
Copy Markdown
Member

@jonatack jonatack May 15, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be helpful to link to a footnote or URL that describes the "available mitigations" (if I'm not confused, I may well be) and consider using a different term here than in the test vectors and acknowledgements sections, if they are referring to different things as they seem to be.


Since [bip-0034][BIP34] activation, explicit [bip-0030][BIP30] validation is not necessary until
block height 1,983,702[^0]. Mandating new coinbase transactions be different from the early
Expand Down Expand Up @@ -102,17 +104,16 @@ increases the preparation cost of an attack, making it uneconomical for a miner[
2500 was chosen as the tightest value that did not make any non-pathological standard transaction
invalid[^7].

In the presence of 64-byte transactions a block header's Merkle root may be valid for different sets
of transactions. This is because, in the Merkle tree construction, a 64-byte value may be
interpreted either as a transaction or as the concatenation of two 32-byte hashes. The former allows faking a block inclusion proof and the latter makes
it such that for a valid block the Merkle root in the block header is not a unique identifier for
the corresponding list of valid transactions[^8]. 64-byte transactions can only contain a
scriptPubKey that lets anyone spend the funds, or one that burns them. 64-byte transactions have
also been non-standard since 2019. It was suggested that the known vulnerabilities could instead be
mitigated by committing to the Merkle tree depth in the header's version field[^9]. The authors
believe it is preferable to address the root cause by invalidating 64-byte transactions. This
approach also fixes the vulnerability without developers of SPV verifiers having to implement the
mitigation or to know it is necessary in the first place.
64-byte transactions can only contain a scriptPubKey that lets anyone spend the funds, or one that
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 discontinuity it
introduces in the set of valid witness-stripped transaction sizes is not worth the marginal
reduction in complexity to SPV verifiers. Others have suggested that the known vulnerabilities could
instead be mitigated by committing to the Merkle tree depth in the header's version field[^8]. The
authors believe it is preferable to address the root cause by invalidating 64-byte transactions,
fixing the vulnerability without developers of SPV verifiers having to implement the mitigation or
Copy link
Copy Markdown
Member

@jonatack jonatack May 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idem here as https://github.com/bitcoin/bips/pull/2159/changes#r3250592381.

to know it 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.

Several blocks prior to [bip-0034][BIP34] activation contain a coinbase transaction whose scriptSig
contains a valid [bip-0034][BIP34] commitment to a future block height. This offers an opportunity
Expand Down Expand Up @@ -146,7 +147,7 @@ Bitcoin Core version [30.0][Core 30.0] and later will not generate a block templ
transaction that violates the signature operations limit introduced in this BIP.

Bitcoin Core version [0.16.1][Core 0.16.1] and later will neither relay nor create block templates
that include 64-byte transactions.
that include transactions whose witness-stripped serialized size is exactly 64 bytes.

The coinbase transaction is usually crafted by mining pool software. To the best of the authors'
knowledge, there does not exist an open source reference broadly in use today for such software.
Expand Down Expand Up @@ -207,11 +208,14 @@ standard transaction size before running into the newly introduced limit. To run
introduced limit but not the transaction size a transaction would need to spend P2SH inputs with a
redeem script similar to `CHECKSIG DROP CHECKSIG DROP ...`. This type of redeem script serves no
purpose beyond increasing its validation cost, which is exactly what this proposal aims to mitigate.
[^8]: See [this writeup][Suhas Merkle] by Suhas Daftuar for an explanation as well as a discussion
of the consequences.
[^9]: By Sergio Demian Lerner in a [blog post][Sergio post] surfaced [by Eric Voskuil][Eric
version]. Eric also pushed back against the importance of fixing this issue. See [this post][64
bytes debate] for an attempt at summarizing the arguments for both sides of this debate.
[^8]: By Sergio Demian Lerner in a [blog post][Sergio post].
[^9]: Conversely, pretending that the inner nodes on one level of the tree are the actual block
transactions is another source of complexity for full node implementations, which previously
resulted in consensus bugs. For instance, Bitcoin Core versions between 0.13.0 and 0.13.2
implemented caching that made it vulnerable to this attack. See [this writeup][Suhas Merkle] by
Suhas Daftuar for a detailed explanation. Invalidating 64-byte transactions may avoid this risk, but
the issue is largely orthogonal to this proposal: it is fundamentally about caching validation
status for malleable blocks.
[^10]: See [here][BIP34 list] for a full list of the heights of historical blocks including a valid
bip-0034 height commitment and the corresponding future block height.
[^11]: Technically it could be argued a duplicate could in principle always be possible before block
Expand All @@ -238,7 +242,6 @@ have to be perpetuated for the Consensus Cleanup.
[ML thread validation time]: https://gnusha.org/pi/bitcoindev/VsltJ2PHqWfzG4BU9YETTXjL7fYBbJhjVXKZQyItemySIA1okvNee9kf0zAOyLMeJ4Nqv1VOrYbWns5nP4TANCWvPJYu1ew_yxQSaudizzk=@protonmail.com
[Suhas Merkle]: https://gnusha.org/pi/bitcoindev/CAFp6fsGtEm9p-ZQF_XqfqyQGzZK7BS2SNp2z680QBsJiFDraEA@mail.gmail.com
[Sergio post]: https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design
[Eric version]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/37
[64 bytes debate]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/41
[BIP34 list]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/4
[Harding nLockTime]: https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core
Expand Down