From: jeremy <jeremy.l.rubin@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
Date: Wed, 6 May 2026 14:35:52 -0700 (PDT) [thread overview]
Message-ID: <43996cb3-9133-4627-8944-5fe08427be68n@googlegroups.com> (raw)
In-Reply-To: <A-Yiqh9r08Wd0V1KwMr7MlVObsiW3esWqySZZzm7aZBV3xBpL0qVJSpF07GfQBoq9YFpBLdlo0k2_tGU5CZ-i0_91MEketsaN8V4FpUnno0=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 7910 bytes --]
I haven't made an *objection*, I've raised an issue and made a request that
the BIP be precise about what it is doing, which is what is generally
expected of BIPs anyway.
You've extrapolated that this is an objection, but it's not. I, or someone
else, may object later, but I at least wanted to do the groundwork of
ensuring that we, the community at large, are on the same page and
discussing the same set of issues. Irrespective of such a future
discussion, I think these clarifications materially improve the BIP
On the similarity of anyone-can-spend-now and anyone-can-spend-later, it is
not true that OP_TRUE, 52416 CSV, and 1 CSV are all equivalent.
They may be equivalent from the point of view of authorization *"once
spendable, no specific key is required" *but they are certainly not
equivalent from a miner-incentive point of view.
A miner has incentive to include a transaction creating an OP_TRUE output
and immediately (assuming sufficient value) spend it to themselves.
Inclusion of 1 CSV outputs in a block can incentivize a future miner to
build on top of that block as "fee forwarding" (and, in a sense, a user may
have incentive to generate 1 CSV, 2 CSV, ... outputs if they are doing a
large transaction with a large fee during a low fee period where they want
to reduce fee-sniping reorg instability).
A protocol can use delays like 52416 CSV for punishments where collusion
with miners is undesirable, since the time of punishment and time of redeem
are far spread.
I agree these can all be called *anyone-can-spend* in a narrow
authorization sense. But they are not equivalent economically. The timing
changes who can capture the value, when they can capture it, and what
incentives are created for inclusion, reorgs, chain extension, and miner
collusion.
Economic distinctions matter. We should not treat *anyone-can-spend now* and
*anyone-can-spend later* as the same thing.
On Wednesday, May 6, 2026 at 4:43:26 AM UTC-7 Antoine Poinsot wrote:
> Hi Jeremy,
>
> Thanks for taking the time to lay out your objection here. I’m glad we now
> have
> a clear statement of it.
>
> As AJ points out, your examples are all anyone-can-spend, so BIP 54 is
> correct
> here. But it's fair that it could be clearer with regard to
> witness-stripped
> serialized size. Thanks for pointing this, i'll push an update.
>
> What's more important is your claim that invalidating 64-byte transactions
> could complicate working with advanced scripting features that may
> eventually
> be added to Bitcoin. If that's the case i agree it should *at least* be
> discussed in BIP 54's rationale section.
>
> However, every time this was brought up, no one could come up with an
> example
> that barely resembles today's Bitcoin. Of course one can come up with
> hypothetical constructions of a very different Bitcoin in which a 64-byte
> transaction could be useful. But that is not the goal. The goal is to find
> a
> script for a 64-byte transaction that is *plausible* Bitcoin would adopt
> in the
> future.
>
> And as long as we are going to have a model where coins commit to their
> spending conditions, a 64-byte transaction is always either burning the
> spent
> coin's value or letting anyone spend it, regardless of the introspection or
> covenanty features that get added to these spending conditions.
>
> Therefore i do not currently see any plausible Bitcoin scripting upgrade
> that
> not only could not be designed to accommodate the 64-byte witness-stripped
> size
> exception, but also whose usage could even result in a 64-byte transaction
> in
> the first place.
>
> Antoine
>
>
> On Friday, May 1st, 2026 at 5:15 PM, jeremy <jeremy....@gmail.com> wrote:
>
> > 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 BytesE) 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+...@googlegroups.com.
> > To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532-4f4cea2b83ecn%40googlegroups.com
> .
>
--
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/43996cb3-9133-4627-8944-5fe08427be68n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9375 bytes --]
prev parent reply other threads:[~2026-05-06 21:45 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
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 [this message]
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=43996cb3-9133-4627-8944-5fe08427be68n@googlegroups.com \
--to=jeremy.l.rubin@gmail.com \
--cc=bitcoindev@googlegroups.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