From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 01 May 2026 14:15:21 -0700 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wIvCj-0003Qf-1P for bitcoindev@gnusha.org; Fri, 01 May 2026 14:15:21 -0700 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-42c06895be6sf5406631fac.0 for ; Fri, 01 May 2026 14:15:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777670115; x=1778274915; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=/H6/4j7847xcjBH+fWut4cA03ARikSx8LXu0aviK4Fs=; b=yFpYB+y1xVmv+HsaY4feRAK72SjUg03PsugxOK6dkfPF3rUwkFAaZYP7MiOqYSLfT0 aIakVTg1TxVQ4OjQRRgfZ43oKOqoj4EZbwnDhL0YMD6oVCAe+0mZ56WLzhY6LWJdvT2N SV0x9LD3EYQwZKdQlYqD4VYsyJW9DedBow4dgApCRvoUHDJNtZpi9AquYUaH++ByO8B6 pZ41OedBdfp2MSWrSh/crkpEBXhvjBPTkMPH8MrCdiAA4yx9XsrLHQRBWmnluKXa7c1R aPqWW23GTz5Uf1dSdzPJ5MGjyahp3BpozXZMzNKg4WISl7kFwKgwzt/ir4EheMtAYESZ Shew== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777670115; x=1778274915; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=/H6/4j7847xcjBH+fWut4cA03ARikSx8LXu0aviK4Fs=; b=fXrwI6+e7SAOflvpvIo/K6mnmrv0LkcrJPpyrbFK4K8G36U9kR+b/eHXB9OyS5arhu BRcEsUAVaU5jFV5tJAl0EGF50+U99VDL9DOwx3kvA1o4S1LqtKT50S/ccfphP9i4ygCR vGTZ6BQmytWThDtDFqpRZsxoS0H4hBSHesm5AkeNvjtUNz59uWy/NL5FkIpsEIhCl6iX P8kD2U1E50JxgaoMeXqNxebfenDTx3c/K5TWEEK+GDujCNVHKjraUjyZc9iz0arxwEyA NKFSlh6d2EoEnGMytGJDkCXXbMcLeAsDiRAq5xi/9p/HCUYAdgDfPdZ8O2rg++t748bM t7Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777670115; x=1778274915; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=/H6/4j7847xcjBH+fWut4cA03ARikSx8LXu0aviK4Fs=; b=mLdG3wfa8VLSDb62hyKIJhzZ9/Dl+ouz7wql1Y1SrcR5FVOQ1Qd2CaG51VceBvWPn/ A8DOJVZAbrQt5FLKGlcAhTm2J5FsV191iCow0AYb5Q35ypdwQ0EHPoNGIaLwuWiCVHdZ N5kE3rdXWzHtMPNRKdlda3RL5rmPtxc0Y19R1oiazgKngsGRmEHTqga2QGBmP8HlsFQV B1giRFiegRR8rRYR1aDg2UCazUz5yM5S5/o0mO+gc56m8PFyn0C3XfG7z9HgBepP1NMJ AMcj6K71BjG+vq/zUI/nqs8UjVII28orgKcf/smZKDMiZ4qXqo53vlXJbQKjLp2YS+tn Dekw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ8DleXY4E9l5wb2cKdf1YM4iPjrtgoA/6GRUJrOc27ix5FcgvyAHFmqpiSd9uXuwCPFDPtdogJyJCqO@gnusha.org X-Gm-Message-State: AOJu0YzN2ItOUfliU6v8HrQ0fYtx5t4eGA7ZoqXFAqkrMDgpnbwl8awQ h4+098V698haKNKbFmrx9+BIeGJiEllASv8Fpdaz4B3YH3tShSr//4R8 X-Received: by 2002:a05:6820:824:b0:694:980a:2c47 with SMTP id 006d021491bc7-6969753ad8cmr457891eaf.0.1777670114773; Fri, 01 May 2026 14:15:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMNLQAprS5y3nG8nsmnvyiZaXsRJL9xxfpNyiDi6LAhVSQ==" Received: by 2002:a05:6820:827:b0:696:281a:fa55 with SMTP id 006d021491bc7-69691213cc2ls555283eaf.2.-pod-prod-01-us; Fri, 01 May 2026 14:15:09 -0700 (PDT) X-Received: by 2002:a05:6808:1917:b0:479:f370:fac0 with SMTP id 5614622812f47-47c8902ee7bmr696981b6e.18.1777670109094; Fri, 01 May 2026 14:15:09 -0700 (PDT) Received: by 2002:a05:690c:578f:b0:79a:c9dc:1f8d with SMTP id 00721157ae682-7bd7670b083ms7b3; Fri, 1 May 2026 14:14:36 -0700 (PDT) X-Received: by 2002:a05:690c:f09:b0:7ba:f2f1:86b5 with SMTP id 00721157ae682-7bd76fa52f8mr11752097b3.14.1777670075952; Fri, 01 May 2026 14:14:35 -0700 (PDT) Date: Fri, 1 May 2026 14:14:35 -0700 (PDT) From: jeremy To: Bitcoin Development Mailing List Message-Id: <123e5545-2eda-4eca-9532-4f4cea2b83ecn@googlegroups.com> Subject: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_160850_1733508875.1777670075345" 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_160850_1733508875.1777670075345 Content-Type: multipart/alternative; boundary="----=_Part_160851_448326289.1777670075345" ------=_Part_160851_448326289.1777670075345 Content-Type: text/plain; charset="UTF-8" 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. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532-4f4cea2b83ecn%40googlegroups.com. ------=_Part_160851_448326289.1777670075345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For fun, let's start with a pop-quiz:

Selec= t all that apply: There can exist a transaction of ___ bytes serialized siz= e that BIP-0054's 64-byte restriction invalidates:

A) 64 BytesB) 0 Bytes
C) 1.5MB
D) 32 Bytes
E) 5MB


T= he answer is A, 64 Bytes, and -- perhaps surprisingly -- C, 1.5MB.=C2=A0
Why is this the case?

BIP-0054 uses the term 64-byte tr= ansaction, but defines it as follows:

> Transact= ions whose witness-stripped serialized size is exactly 64 bytes are invalid= .

In a [personally run] straw-poll of devs a= t 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 s= entences throughout the BIP as:

> t= ransactions 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 esse= ntially useless:

> 64-byte transactions ca= n only contain a scriptPubKey that lets anyone spend the funds, or one that= burns them.

This is not strictly corr= ect. Here are a few examples of current and future uses for 64-byte transac= tions:

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 us= ed 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 wo= rk which might use output scripts for e.g. Transaction Sponsor encodings
- Future covenants work which encodes time-of-creation run scr= ipts that e.g. quine an input; possibly in conjunction with sponsors
<= /div>
- Future where we have expensive reusable PQ or Contract public k= eys 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 p= adding 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 let= s anyone spend the funds, or one that burns them.

With some= thing 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 prot= ecting.

Or a more accurate reflection= of the BIP-0054 authors' opinion.

Jeremy

--
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/123e5545-2eda-4eca-9532-4f4cea2b83ecn%40googlegroups.com.
------=_Part_160851_448326289.1777670075345-- ------=_Part_160850_1733508875.1777670075345--