From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 06 May 2026 14:45:40 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wKk3m-0003Ly-Vz for bitcoindev@gnusha.org; Wed, 06 May 2026 14:45:40 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-40f25e55f20sf128842fac.0 for ; Wed, 06 May 2026 14:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778103933; x=1778708733; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=ApRkzLdVEf8x7kuaVkUsocJVkwG/V9wn/d2DTCyiphA=; b=k1ped/lv7v/dNXQ4ScG51xNORd3S+9Uq+PCh5KeQwpfRffGe67yL347mGYSoWFU/yw 173wZA8+8KrM+ZRbJqyr2kL6epvKpf0kPoF7pz5vZbBXhmuBOnsDBu4KrgIcipMhFc80 v6hftmhZJy2jt0wTDtjpKuWe4WJKNelCf33rPaaOXV4pRYwNLOeApm95Qaz7m/89wkcI HxRKoZpdMNhuaKvI7jowHAtEikop37xHiCeexd81KnniIfblSEYk+GlCTMLatELNjdPu 4a7l6iefZsrZB5tbgm6WowOSymN6LzWS//hiLxgX5vrlJI6W7bq7y5FAbyQbCbHSTP1/ gwsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778103933; x=1778708733; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=ApRkzLdVEf8x7kuaVkUsocJVkwG/V9wn/d2DTCyiphA=; b=enaAEEEpEkmpY/yxo7Dv1/dm0YTBOZzfilRln/LcbvJIKDC75aLQuF+DnwaYgt49+Y I97YEdHN1d9T42QUYu1+p46qlAgWZh8UMXA/k3G9TaG05Q+UKV54T9Xdg44vHlIJqLBk Ob38rKj0dA7uLFxbwZ+Ca/yCg4IDxaYmo1G0FeBCPbYxQPg3oS21xXvO/dWCPpSmz6/+ Whho5SYt5TW/i9OLZzgoMKljlkEN4ks5uw0lTioqKUYMQzEjxBPhC7dRDLeY7oZdjBKP HVC/FX9xDuTbI3VMMusOe2v0aDl+PIga1Bm317VYwHZ2s+1ZapI4Zxd7uhPx6vl6WqZE o75A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778103933; x=1778708733; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=ApRkzLdVEf8x7kuaVkUsocJVkwG/V9wn/d2DTCyiphA=; b=E0UgBiLkBipgjE5q4Cw/BFF2wx7YIjzJmNlUhQB02jinRAaKdzRxT6YSy9+R+zuVCu UCfRZbj6suDMNHwUEE3qfFZljWyQCEFhCinbWQqm8nK0fwBfoVmeWeHFiPX6tgnivDhK 8C3LD4ItzbcHF2ffhiH0/2sbMDBJanuGP5geYwyNLF5LPoETWKZ21kjnDuOQsJp1IhDj ob7DSDvjnYNVnapU3+g55G+LyF9igU8UjWOv/jBbHqQ9LT8Td+5kpGTpKR3W318bpgUk xG179YlX9Z+BMh/Abof4p7z4ZVU5K3tG8ajcZj59cc5Uh++hnUYiyWUZ9PFXZ942pYLo 1ggg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/iCBRYmAzflDtkneuaCkahuZZVPgUvu8JXhfQR25Yy5pVizKLgOugHtmHBTHMidvr1+cznYh6k66oR@gnusha.org X-Gm-Message-State: AOJu0YxfJRAduzkXmRR3GRiZGkRDwFiUNu8KXDnHYov/88xUZcn7nwfL g76rLV+EEjiYFODqa7PF7Vu3uLFilQfbSWoRW9Ea55iyU4/nERDPcHbN X-Received: by 2002:a05:6870:96aa:b0:42c:5ca:e7f7 with SMTP id 586e51a60fabf-434f66395d5mr3369613fac.23.1778103932615; Wed, 06 May 2026 14:45:32 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMN47VNSOHA/m/H3jsWHmoPlug9j0X/ZNiAGwGyn1EibQ==" Received: by 2002:a05:6870:e386:b0:42c:22ed:f980 with SMTP id 586e51a60fabf-43525072c1fls104272fac.0.-pod-prod-01-us; Wed, 06 May 2026 14:45:27 -0700 (PDT) X-Received: by 2002:a05:6808:3a17:b0:479:ead7:2a5a with SMTP id 5614622812f47-480420d7c0cmr3394934b6e.11.1778103927292; Wed, 06 May 2026 14:45:27 -0700 (PDT) Received: by 2002:a05:690c:e5d0:b0:7ba:f5aa:4ab8 with SMTP id 00721157ae682-7bd762822c7ms7b3; Wed, 6 May 2026 14:35:54 -0700 (PDT) X-Received: by 2002:a05:690c:6e81:b0:7bd:6a98:58db with SMTP id 00721157ae682-7bdf5e02adbmr59127677b3.22.1778103353717; Wed, 06 May 2026 14:35:53 -0700 (PDT) Date: Wed, 6 May 2026 14:35:52 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <43996cb3-9133-4627-8944-5fe08427be68n@googlegroups.com> In-Reply-To: References: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> Subject: Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_167232_1084798031.1778103352983" X-Original-Sender: Jeremy.L.Rubin@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_167232_1084798031.1778103352983 Content-Type: multipart/alternative; boundary="----=_Part_167233_2121547819.1778103352983" ------=_Part_167233_2121547819.1778103352983 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't made an *objection*, I've raised an issue and made a request that= =20 the BIP be precise about what it is doing, which is what is generally=20 expected of BIPs anyway. You've extrapolated that this is an objection, but it's not. I, or someone= =20 else, may object later, but I at least wanted to do the groundwork of=20 ensuring that we, the community at large, are on the same page and=20 discussing the same set of issues. Irrespective of such a future=20 discussion, I think these clarifications materially improve the BIP On the similarity of anyone-can-spend-now and anyone-can-spend-later, it is= =20 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=20 spendable, no specific key is required" *but they are certainly not=20 equivalent from a miner-incentive point of view. A miner has incentive to include a transaction creating an OP_TRUE output= =20 and immediately (assuming sufficient value) spend it to themselves. Inclusion of 1 CSV outputs in a block can incentivize a future miner to=20 build on top of that block as "fee forwarding" (and, in a sense, a user may= =20 have incentive to generate 1 CSV, 2 CSV, ... outputs if they are doing a=20 large transaction with a large fee during a low fee period where they want= =20 to reduce fee-sniping reorg instability). A protocol can use delays like 52416 CSV for punishments where collusion=20 with miners is undesirable, since the time of punishment and time of redeem= =20 are far spread. I agree these can all be called *anyone-can-spend* in a narrow=20 authorization sense. But they are not equivalent economically. The timing= =20 changes who can capture the value, when they can capture it, and what=20 incentives are created for inclusion, reorgs, chain extension, and miner=20 collusion. Economic distinctions matter. We should not treat *anyone-can-spend now* an= d=20 *anyone-can-spend later* as the same thing. On Wednesday, May 6, 2026 at 4:43:26=E2=80=AFAM UTC-7 Antoine Poinsot wrote= : > Hi Jeremy, > > Thanks for taking the time to lay out your objection here. I=E2=80=99m gl= ad we now=20 > have > a clear statement of it. > > As AJ points out, your examples are all anyone-can-spend, so BIP 54 is=20 > correct > here. But it's fair that it could be clearer with regard to=20 > witness-stripped > serialized size. Thanks for pointing this, i'll push an update. > > What's more important is your claim that invalidating 64-byte transaction= s > could complicate working with advanced scripting features that may=20 > 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=20 > 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 fin= d=20 > a > script for a 64-byte transaction that is *plausible* Bitcoin would adopt= =20 > 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= =20 > 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= =20 > that > not only could not be designed to accommodate the 64-byte witness-strippe= d=20 > size > exception, but also whose usage could even result in a 64-byte transactio= n=20 > in > the first place. > > Antoine > > > On Friday, May 1st, 2026 at 5:15 PM, jeremy wrote: > > > For fun, let's start with a pop-quiz: > >=20 > > Select all that apply: There can exist a transaction of ___ bytes=20 > serialized size that BIP-0054's 64-byte restriction invalidates: > >=20 > > A) 64 Bytes > > B) 0 Bytes > > C) 1.5MB > > D) 32 BytesE) 5MB > >=20 > >=20 > > The answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB. > >=20 > > Why is this the case? > >=20 > > BIP-0054 uses the term 64-byte transaction, but defines it as follows: > > > Transactions whose witness-stripped serialized size is exactly 64=20 > bytes are invalid. > >=20 > > In a [personally run] straw-poll of devs at a recent conference, no-one= =20 > knew this precise edge condition or that the transactions could have a=20 > meaningful witness. For clarity, the restriction on bytes is on=20 > INVALID_TX_NONWITNESS_SIZE, not on the size with Witness. > > Therefore, it is more accurate to refer to this in all sentences=20 > throughout the BIP as: > >=20 > >=20 > > > transactions with exactly 64 bytes of non-witness data, > >=20 > > due to the propensity for confusion. > >=20 > > BIP-0054 also makes a comment that the transactions it invalidates are= =20 > essentially useless: > >=20 > > > 64-byte transactions can only contain a scriptPubKey that lets anyone= =20 > spend the funds, or one that burns them. > >=20 > >=20 > > This is not strictly correct. Here are a few examples of current and=20 > future uses for 64-byte transactions: > >=20 > > Current Uses: > > - A transaction that donates to a future miner from a segwit (any=20 > version) output via a spend to something like <512> OP_CSV (-> push2 byte= s=20 > 512 csv -> 0x02 0x00 0x02 0xb2) > > - That same output which is used as a connector output for things that= =20 > should be claimed by a miner at a future time > > - Pay-to-Anchor / ephemeral anchor outputs -- while typically p2a is fo= r=20 > txns you want to add a subsidy ability, a 64-byte txn could be used to sh= im=20 > a keyed anchor to a p2a output after a certain delay. > >=20 > > Future Uses: > > - Future work which might use output scripts for e.g. Transaction=20 > Sponsor encodings > > - Future covenants work which encodes time-of-creation run scripts that= =20 > e.g. quine an input; possibly in conjunction with sponsors > > - Future where we have expensive reusable PQ or Contract public keys=20 > that are posted once and referred to by index > >=20 > >=20 > > While, in a sense, current uses are much more concerning than future=20 > uses, with introspection opcodes, it might create substantive additional= =20 > complexity to ensure that there is always a valid way to add a padding by= te=20 > without upsetting a state machine. > >=20 > > As there are now documented use cases for 64-byte transactions that thi= s=20 > proposal makes more difficult to do, I recommend replacing the text in th= e=20 > BIP that says > >=20 > > > 64-byte transactions can only contain a scriptPubKey that lets anyone= =20 > spend the funds, or one that burns them. > >=20 > > With something like: > > > There are documented use cases for 64-byte transactions that this=20 > proposal makes more difficult to cleanly do, but we do not believe these= =20 > use cases will ever be valuable or worth protecting. > >=20 > >=20 > > Or a more accurate reflection of the BIP-0054 authors' opinion. > >=20 > > Jeremy > >=20 > >=20 > > -- > > You received this message because you are subscribed to the Google=20 > Groups "Bitcoin Development Mailing List" group. > > To unsubscribe from this group and stop receiving emails from it, send= =20 > an email to bitcoindev+...@googlegroups.com. > > To view this discussion visit=20 > https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532-4f4c= ea2b83ecn%40googlegroups.com > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 43996cb3-9133-4627-8944-5fe08427be68n%40googlegroups.com. ------=_Part_167233_2121547819.1778103352983 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't made an=C2=A0objection, I've raised an issue and made a re= quest that the BIP be precise about what it is doing, which is what is gene= rally expected of BIPs anyway.

You've extrapolated tha= t 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 commun= ity at large, are on the same page and discussing the same set of issues. I= rrespective of such a future discussion, I think these clarifications mater= ially improve the BIP

On the similarity of anyon= e-can-spend-now and anyone-can-spend-later, it is not true that OP_TRUE,=C2= =A0 52416 CSV, and 1 CSV are all equivalent.

The= y may be equivalent from the point of view of authorization "once spenda= ble, no specific key is required"=C2=A0=C2=A0but 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.
<= div>
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 c= ollusion with miners is undesirable, since the time of punishment and time = of redeem are far spread.

I agree these ca= n all be called anyone-can-spend in a narrow authorization sense. Bu= t they are not equivalent economically. The timing changes who can capture = the value, when they can capture it, and what incentives are created for in= clusion, reorgs, chain extension, and miner collusion.

Economic distinctions matter. We should not treat=C2=A0anyone-can= -spend now=C2=A0and anyone-can-spend later as the same thing.

On Wednesday, May 6, 2026 at 4:43:26=E2=80=AFAM UTC-7 Antoine Poinsot w= rote:
Hi Jere= my,

Thanks for taking the time to lay out your objection here. I=E2=80=99m = 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 trans= actions
could complicate working with advanced scripting features that may even= tually
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 e= xample
that barely resembles today's Bitcoin. Of course one can come up wi= th
hypothetical constructions of a very different Bitcoin in which a 64-by= te
transaction could be useful. But that is not the goal. The goal is to f= ind a
script for a 64-byte transaction that is *plausible* Bitcoin would adop= t 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 introspe= ction or
covenanty features that get added to these spending conditions.

Therefore i do not currently see any plausible Bitcoin scripting upgrad= e that
not only could not be designed to accommodate the 64-byte witness-strip= ped size
exception, but also whose usage could even result in a 64-byte transact= ion 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:
>=20
> Select all that apply: There can exist a transaction of ___ bytes = serialized size that BIP-0054's 64-byte restriction invalidates:
>=20
> A) 64 Bytes
> B) 0 Bytes
> C) 1.5MB
> D) 32 BytesE) 5MB
>=20
>=20
> The answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB= .
>=20
> Why is this the case?
>=20
> BIP-0054 uses the term 64-byte transaction, but defines it as foll= ows:
> > Transactions whose witness-stripped serialized size is exactl= y 64 bytes are invalid.
>=20
> In a [personally run] straw-poll of devs at a recent conference, n= o-one knew this precise edge condition or that the transactions could have = a meaningful witness. For clarity, the restriction on bytes is on INVALID_T= X_NONWITNESS_SIZE, not on the size with Witness.
> Therefore, it is more accurate to refer to this in all sentences t= hroughout the BIP as:
>=20
>=20
> > transactions with exactly 64 bytes of non-witness data,
>=20
> due to the propensity for confusion.
>=20
> BIP-0054 also makes a comment that the transactions it invalidates= are essentially useless:
>=20
> > 64-byte transactions can only contain a scriptPubKey that let= s anyone spend the funds, or one that burns them.
>=20
>=20
> This is not strictly correct. Here are a few examples of current a= nd future uses for 64-byte transactions:
>=20
> 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 (-> pus= h2 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.
>=20
> 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 ke= ys that are posted once and referred to by index
>=20
>=20
> While, in a sense, current uses are much more concerning than futu= re uses, with introspection opcodes, it might create substantive additional= complexity to ensure that there is always a valid way to add a padding byt= e without upsetting a state machine.
>=20
> As there are now documented use cases for 64-byte transactions tha= t this proposal makes more difficult to do, I recommend replacing the text = in the BIP that says
>=20
> > 64-byte transactions can only contain a scriptPubKey that let= s anyone spend the funds, or one that burns them.
>=20
> 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 the= se use cases will ever be valuable or worth protecting.
>=20
>=20
> Or a more accurate reflection of the BIP-0054 authors' opinion= .
>=20
> Jeremy
>=20
>=20
> --
> 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-4f4cea2b83e= cn%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/43996cb3-9133-4627-8944-5fe08427be68n%40googlegroups.com.
------=_Part_167233_2121547819.1778103352983-- ------=_Part_167232_1084798031.1778103352983--