From: <eric@voskuil.org>
To: "'jeremy'" <jeremy.l.rubin@gmail.com>,
"'Bitcoin Development Mailing List'"
<bitcoindev@googlegroups.com>
Subject: RE: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
Date: Fri, 1 May 2026 18:03:31 -0400 [thread overview]
Message-ID: <00a501dcd9b6$59406560$0bc13020$@voskuil.org> (raw)
In-Reply-To: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com>
Thanks Jeremey for this additional information. This exclusion is one of the reasons I originally pushed back, but I wasn't personally aware of any current use cases.
I would also suggest that the Rational section text in this area, while referencing my critiques in a footnote, doesn't capture the essence of them in the paragraph. It points out that I pushed back on importance, but excludes the reasons, which I consider essential in terms of making an informed decision. There is a referenced thread on Delving, and a related discussion on bitcoin-dev. I won't recount the details here, but I think the paragraph could more fairly represent the discussion, including the fact that the technical aspects were eventually agreed.
The TLDR is that:
(1) Merkle root malleation affects validation optimizations, not validation inherently.
(2) both forms of malleation can be mitigated by a node with no material performance hit (we do this).
(3) the material impact is to SPV wallets, as they must obtain the coinbase to mitigate.
This reference:
"It was suggested that the known vulnerabilities could instead be mitigated by committing to the Merkle tree depth in the header's version field"
Was added to the discussion by me, but is not the essence of my critique. It pertains to #3 and is not necessary for a node to mitigate malleation.
My pushback was that we are trading optimization implementation details for a consensus rule, and that the rule could create unforeseen problems by otherwise arbitrarily restricting the tx domain (which you have now pointed out below). I did not assume that everyone would see this modest SPV wallet benefit as worth the tradeoff. I am not personally taking a stand on that question, but I do think it could be presented more clearly.
Best,
Eric
> -----Original Message-----
> From: bitcoindev@googlegroups.com <bitcoindev@googlegroups.com> On
> Behalf Of jeremy
> Sent: Friday, May 1, 2026 5:15 PM
> To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
> Subject: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential
> Legitimate Uses
>
> For fun, let's start with a pop-quiz:
>
> Select all that apply: There can exist a transaction of ___ bytes serialized size
> that BIP-0054's 64-byte restriction invalidates:
>
> A) 64 Bytes
> B) 0 Bytes
> C) 1.5MB
> D) 32 Bytes
> E) 5MB
>
>
> The answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB.
>
> Why is this the case?
>
> BIP-0054 uses the term 64-byte transaction, but defines it as follows:
>
> > Transactions whose witness-stripped serialized size is exactly 64 bytes are
> invalid.
>
> In a [personally run] straw-poll of devs at a recent conference, no-one knew
> this precise edge condition or that the transactions could have a meaningful
> witness. For clarity, the restriction on bytes is on
> INVALID_TX_NONWITNESS_SIZE, not on the size with Witness.
>
> Therefore, it is more accurate to refer to this in all sentences throughout the
> BIP as:
>
>
> > transactions with exactly 64 bytes of non-witness data,
>
> due to the propensity for confusion.
>
> BIP-0054 also makes a comment that the transactions it invalidates are
> essentially useless:
>
> > 64-byte transactions can only contain a scriptPubKey that lets anyone spend
> the funds, or one that burns them.
>
>
> This is not strictly correct. Here are a few examples of current and future uses
> for 64-byte transactions:
>
> Current Uses:
> - A transaction that donates to a future miner from a segwit (any version)
> output via a spend to something like <512> OP_CSV (-> push2 bytes 512 csv -
> > 0x02 0x00 0x02 0xb2)
> - That same output which is used as a connector output for things that should
> be claimed by a miner at a future time
> - Pay-to-Anchor / ephemeral anchor outputs -- while typically p2a is for txns
> you want to add a subsidy ability, a 64-byte txn could be used to shim a keyed
> anchor to a p2a output after a certain delay.
>
>
> Future Uses:
> - Future work which might use output scripts for e.g. Transaction Sponsor
> encodings
> - Future covenants work which encodes time-of-creation run scripts that e.g.
> quine an input; possibly in conjunction with sponsors
> - Future where we have expensive reusable PQ or Contract public keys that are
> posted once and referred to by index
>
>
> While, in a sense, current uses are much more concerning than future uses,
> with introspection opcodes, it might create substantive additional complexity
> to ensure that there is always a valid way to add a padding byte without
> upsetting a state machine.
>
> As there are now documented use cases for 64-byte transactions that this
> proposal makes more difficult to do, I recommend replacing the text in the BIP
> that says
>
> > 64-byte transactions can only contain a scriptPubKey that lets anyone spend
> the funds, or one that burns them.
>
> With something like:
>
> > There are documented use cases for 64-byte transactions that this proposal
> makes more difficult to cleanly do, but we do not believe these use cases will
> ever be valuable or worth protecting.
>
>
> Or a more accurate reflection of the BIP-0054 authors' opinion.
>
> Jeremy
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com
> <mailto:bitcoindev+unsubscribe@googlegroups.com> .
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532-
> 4f4cea2b83ecn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-
> 9532-
> 4f4cea2b83ecn%40googlegroups.com?utm_medium=email&utm_source=foo
> ter> .
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/00a501dcd9b6%2459406560%240bc13020%24%40voskuil.org.
next prev parent reply other threads:[~2026-05-01 22:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 21:14 [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses jeremy
2026-05-01 22:03 ` eric [this message]
2026-05-14 13:50 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-05-02 5:29 ` Anthony Towns
2026-05-02 15:26 ` Chris Stewart
2026-05-02 18:09 ` jeremy
2026-05-06 11:10 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2026-05-06 21:35 ` jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00a501dcd9b6$59406560$0bc13020$@voskuil.org' \
--to=eric@voskuil.org \
--cc=bitcoindev@googlegroups.com \
--cc=jeremy.l.rubin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox