Unnamed repository; edit this file 'description' to name the repository.
 help / color / mirror / Atom feed

* [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
@ 2026-05-01 21:14 jeremy
  2026-05-01 22:03 ` eric
                   ` (3 more replies)
  0 siblings, 4 replies; 8+ messages in thread
From: jeremy @ 2026-05-01 21:14 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 3336 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 4277 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

• * RE: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
    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
                     ` (2 subsequent siblings)
    3 siblings, 1 reply; 8+ messages in thread
  From: eric @ 2026-05-01 22:03 UTC (permalink / raw)
    To: 'jeremy', 'Bitcoin Development Mailing List'
  
  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.
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: RE: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
      2026-05-01 22:03 ` eric
    @ 2026-05-14 13:50   ` 'Antoine Poinsot' via Bitcoin Development Mailing List
      0 siblings, 0 replies; 8+ messages in thread
    From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-05-14 13:50 UTC (permalink / raw)
      To: eric; +Cc: 'jeremy', 'Bitcoin Development Mailing List'
    
    Hi Eric,
    
    Fair enough. The BIP rationale should discuss explicitly your point that it introduces a "seam", instead of just mentioning it in a footnote. Also i clarified how the full node consensus failure point is not the motivation for 64-byte txs invalidations since it can be better addressed differently, as you previously pointed.
    
    Changes here: https://github.com/bitcoin/bips/pull/2159. Also took Jeremy's feedback that "64-byte transactions" should spell out that it refers to witness-stripped serialized in more places than only the specifications.
    
    Best,
    Antoine
    
    -------- Original Message --------
    On Saturday, 05/02/26 at 00:15 eric@voskuil.org wrote:
    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.
    
    -- 
    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/MgHn_5awXJ1_23y-bU1gDdEuxICa5pwAthGV4k2H3OHYvpTNLLZvfdXrCUxDvfdOjWAFAgF8KSjyEX2-gB0776yVx8lRI_ztQTO9321HLg4%3D%40protonmail.com.
    
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
    2026-05-01 21:14 [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses jeremy
    2026-05-01 22:03 ` eric
  @ 2026-05-02  5:29 ` Anthony Towns
    2026-05-02 15:26 ` Chris Stewart
    2026-05-06 11:10 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
    3 siblings, 0 replies; 8+ messages in thread
  From: Anthony Towns @ 2026-05-02  5:29 UTC (permalink / raw)
    To: Bitcoin Development Mailing List
  
  On Fri, May 01, 2026 at 02:14:35PM -0700, jeremy wrote:
  > *> 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
  
  This is an anyone can spend transaction. "Donation to a miner" and
  "anyone can spend" are synonyms.
  
  The script "OP_NOP <512> OP_CSV" would avoid the 64-byte special case
  if anyone were to want to do this. Note that these are not standard
  transactions and will generally not relay today.
  
  > - 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.
  
  This only applies if you're donating an entire output to the miner, in
  order to accelerate / increase the effective feerate of the transaction
  that created that output. You would get a higher feerate by RBFing
  the original transaction to delete the output -- that is, rather than
  generating the transaction as "I'll have a feerate of X or X+Y, by
  signing two transactions, one creating an output, and one spending that
  output to miner fees (possibly with a timelock)", you do "I'll have a
  feerate of X or X+Y+Z, by signing two transactions, one at at feerate X,
  one at feerate X+Y+Z (possibly with a timelock)".
  
  If there's some case where the two transaction approach does become
  desirable, despite it's inefficiency, introducing an alternative 5-byte
  P2A scriptPubKey would only be a policy change.
  
  Cheers,
  aj
  
  -- 
  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/afWLq1DWaQPWLe45%40erisian.com.au.
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
    2026-05-01 21:14 [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses jeremy
    2026-05-01 22:03 ` eric
    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
    3 siblings, 1 reply; 8+ messages in thread
  From: Chris Stewart @ 2026-05-02 15:26 UTC (permalink / raw)
    To: jeremy; +Cc: Bitcoin Development Mailing List
  
  [-- Attachment #1: Type: text/plain, Size: 5354 bytes --]
  
  I do concede your point that witness stripping isn't well understood by the
  general community. Here is a writeup I did for readers of the mailing list
  that may not understand what Jeremy is talking about the characteristics of
  a 64 byte transaction[0]. There is a big distinction between pre-segwit 64
  byte transactions and segwit 64 byte transactions.
  
  
  > 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)
  
  I find this confusing. Can you give 2 hex encoded transactions (funding
  transaction, spending transaction) that do this? regtest is fine, i can
  just decode locally.
  
  Splitting hairs semantically if understand the transactions you are
  proposing above, "donating" to a "future miner" i.e. sending money to *anyone
  (not a specific someone)* in the future that can mine a block - doesn't
  seem much different to me than "anyone can spend the funds". I'll await
  your transactions though in the case that I am missing something.
  
  [0] -
  https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73?u=chris_stewart_5
  
  On Fri, May 1, 2026 at 4:15 PM jeremy <jeremy.l.rubin@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 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
  > <https://groups.google.com/d/msgid/bitcoindev/123e5545-2eda-4eca-9532-4f4cea2b83ecn%40googlegroups.com?utm_medium=email&utm_source=footer>
  > .
  >
  
  -- 
  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/CAGL6%2BmGeqx8TvWSfSg_FdrbHVy%2B3Sk5VmQ%2B_WPjGjhXbp%3DLiBA%40mail.gmail.com.
  
  [-- Attachment #2: Type: text/html, Size: 6749 bytes --]
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
      2026-05-02 15:26 ` Chris Stewart
    @ 2026-05-02 18:09   ` jeremy
      0 siblings, 0 replies; 8+ messages in thread
    From: jeremy @ 2026-05-02 18:09 UTC (permalink / raw)
      To: Bitcoin Development Mailing List
    
    
    [-- Attachment #1.1: Type: text/plain, Size: 14610 bytes --]
    
    Chris,
    
    These examples should work and could be adapted to a different funding 
    input (I stubbed out the actual signature with just a preimage reveal for 
    simplicity).
    
    
    funding witnessScript: 
    a820ff76f4f923cd475f27097b3822640a9b441894f3d4f742fe70e745e986da388e87 
    funding scriptPubKey: 
    002080c153db1ea3461a2b70126f853189fc34d7d9926f083dfb2bffae8ae2bb1130 
    funding txid: 
    166ef40e58f1a62e01d610023ca7935eef372cf3c1239d81430dffbd1fe8fe9e 
    funding tx hex: 
    02000000010000000000000000000000000000000000000000000000000000000000000000ffffffff020101ffffffff01a08601000000000022002080c153db1ea3461a2b70126f853189fc34d7d9926f083dfb2bffae8ae2bb113000000000 
    
    182 | 
    spending output scriptPubKey: 020002b2 
    spending stripped size: 64 
    spending full size: 114 
    spending txid: 
    44c752f499326a59a78259b455875d296108184b7f25b9a0b41bc018af7aedd8 
    spending wtxid: 
    1e6eb4de698f079cbaa0fdf47d7ab5e1bb4939fae42652f295dd05d15930074d 
    spending tx stripped hex: 
    02000000019efee81fbdff0d43819d23c1f32c37ef5e93a73c0210d6012ea6f1580ef46e160000000000ffffffff01905f01000000000004020002b200000000 
    
    spending tx full hex: 
    020000000001019efee81fbdff0d43819d23c1f32c37ef5e93a73c0210d6012ea6f1580ef46e160000000000ffffffff01905f01000000000004020002b2020a62697035342064656d6f23a820ff76f4f923cd475f27097b3822640a9b441894f3d4f742fe70e745e986da388e8700000000 
    
    
    
    *$ decodrawtransaction $(cat funding_tx.hex)*
    
    {
      "txid": 
    "166ef40e58f1a62e01d610023ca7935eef372cf3c1239d81430dffbd1fe8fe9e",
      "hash": 
    "166ef40e58f1a62e01d610023ca7935eef372cf3c1239d81430dffbd1fe8fe9e",
      "version": 2,
      "size": 96,
      "vsize": 96,
      "weight": 384,
      "locktime": 0,
      "vin": [
        {
          "coinbase": "0101",
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.00100000,
          "n": 0,
          "scriptPubKey": {
            "asm": "0 
    80c153db1ea3461a2b70126f853189fc34d7d9926f083dfb2bffae8ae2bb1130",
            "desc": 
    "addr(bcrt1qsrq48kc75drp52mszfhc2vvfls6d0kvjduyrm7etl7hg4c4mzycqmw604m)#2rrnsnlc",
            "hex": 
    "002080c153db1ea3461a2b70126f853189fc34d7d9926f083dfb2bffae8ae2bb1130",
            "address": 
    "bcrt1qsrq48kc75drp52mszfhc2vvfls6d0kvjduyrm7etl7hg4c4mzycqmw604m",
            "type": "witness_v0_scripthash"
          }
        }
      ]
    }
    
    
    
    *$ decodrawtransaction $(cat spending_tx_stripped.hex)*
    
    
    {
      "txid": 
    "44c752f499326a59a78259b455875d296108184b7f25b9a0b41bc018af7aedd8",
      "hash": 
    "44c752f499326a59a78259b455875d296108184b7f25b9a0b41bc018af7aedd8",
      "version": 2,
      "size": 64,
      "vsize": 64,
      "weight": 256,
      "locktime": 0,
      "vin": [
        {
          "txid": 
    "166ef40e58f1a62e01d610023ca7935eef372cf3c1239d81430dffbd1fe8fe9e",
          "vout": 0,
          "scriptSig": {
            "asm": "",
            "hex": ""
          },
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.00090000,
          "n": 0,
          "scriptPubKey": {
            "asm": "512 OP_CHECKSEQUENCEVERIFY",
            "desc": "raw(020002b2)#vceh5z0j",
            "hex": "020002b2",
            "type": "nonstandard"
          }
        }
      ]
    }
    *$ decodrawtransaction $(cat spending_tx_full.hex)*
    
    {
      "txid": 
    "44c752f499326a59a78259b455875d296108184b7f25b9a0b41bc018af7aedd8",
      "hash": 
    "1e6eb4de698f079cbaa0fdf47d7ab5e1bb4939fae42652f295dd05d15930074d",
      "version": 2,
      "size": 114,
      "vsize": 77,
      "weight": 306,
      "locktime": 0,
      "vin": [
        {
          "txid": 
    "166ef40e58f1a62e01d610023ca7935eef372cf3c1239d81430dffbd1fe8fe9e",
          "vout": 0,
          "scriptSig": {
            "asm": "",
            "hex": ""
          },
          "txinwitness": [
            "62697035342064656d6f",
            
    "a820ff76f4f923cd475f27097b3822640a9b441894f3d4f742fe70e745e986da388e87"
          ],
          "sequence": 4294967295
        }
      ],
      "vout": [
        {
          "value": 0.00090000,
          "n": 0,
          "scriptPubKey": {
            "asm": "512 OP_CHECKSEQUENCEVERIFY",
            "desc": "raw(020002b2)#vceh5z0j",
            "hex": "020002b2",
            "type": "nonstandard"
          }
        }
      ]
    }
    
    
    ```python3
    #!/usr/bin/env python3
    from __future__ import annotations
    
    import hashlib
    import struct
    
    
    OP_SHA256 = 0xA8
    OP_EQUAL = 0x87
    OP_CHECKSEQUENCEVERIFY = 0xB2
    
    
    def sha256(b: bytes) -> bytes:
        return hashlib.sha256(b).digest()
    
    
    def hash256(b: bytes) -> bytes:
        return hashlib.sha256(hashlib.sha256(b).digest()).digest()
    
    
    def hash256_be_hex(b: bytes) -> str:
        return hash256(b)[::-1].hex()
    
    
    def compact_size(n: int) -> bytes:
        if n < 0:
            raise ValueError("negative compact size")
        if n < 253:
            return bytes([n])
        if n <= 0xFFFF:
            return b"\xfd" + struct.pack("<H", n)
        if n <= 0xFFFFFFFF:
            return b"\xfe" + struct.pack("<I", n)
        return b"\xff" + struct.pack("<Q", n)
    
    
    def i32(n: int) -> bytes:
        return struct.pack("<i", n)
    
    
    def u32(n: int) -> bytes:
        return struct.pack("<I", n)
    
    
    def u64(n: int) -> bytes:
        return struct.pack("<Q", n)
    
    
    def ser_output(value_sat: int, script_pubkey: bytes) -> bytes:
        return u64(value_sat) + compact_size(len(script_pubkey)) + script_pubkey
    
    
    def ser_input(prev_txid_be_hex: str, vout: int, script_sig: bytes = b"", 
    sequence: int = 0xFFFFFFFF) -> bytes:
        # Transaction outpoints serialize txids little-endian.
        prev_txid_le = bytes.fromhex(prev_txid_be_hex)[::-1]
        return (
            prev_txid_le
            + u32(vout)
            + compact_size(len(script_sig))
            + script_sig
            + u32(sequence)
        )
    
    
    # --------------------------------------------------------------------
    # Funding transaction
    # --------------------------------------------------------------------
    #
    # This is a coinbase-like funding transaction for a decode/test vector.
    # It pays 100_000 sats to a native P2WSH output.
    #
    # witnessScript:
    #
    #   OP_SHA256 <sha256("bip54 demo")> OP_EQUAL
    #
    # The spending transaction must reveal the preimage "bip54 demo" in witness.
    
    secret = b"bip54 demo"
    secret_hash = sha256(secret)
    
    witness_script = (
        bytes([OP_SHA256])
        + bytes([0x20])       # push 32 bytes
        + secret_hash
        + bytes([OP_EQUAL])
    )
    
    # Native v0 P2WSH scriptPubKey:
    #
    #   OP_0 <sha256(witness_script)>
    #
    funding_script_pubkey = b"\x00\x20" + sha256(witness_script)
    
    coinbase_script_sig = b"\x01\x01"  # BIP34-style height=1 push; enough for 
    a decode vector.
    
    funding_tx = (
        i32(2)
        + compact_size(1)
        + bytes(32)                  # coinbase prevout txid = 0x00..00
        + u32(0xFFFFFFFF)            # coinbase prevout index
        + compact_size(len(coinbase_script_sig))
        + coinbase_script_sig
        + u32(0xFFFFFFFF)
        + compact_size(1)
        + ser_output(100_000, funding_script_pubkey)
        + u32(0)
    )
    
    funding_txid = hash256_be_hex(funding_tx)
    
    
    # --------------------------------------------------------------------
    # Spending transaction
    # --------------------------------------------------------------------
    #
    # This spends funding_tx output 0.
    #
    # The sole output scriptPubKey is:
    #
    #   <512> OP_CHECKSEQUENCEVERIFY
    #
    # Minimal ScriptNum encoding for decimal 512 is little-endian 00 02,
    # so the full script is:
    #
    #   02 00 02 b2
    #
    # This spending transaction has:
    #
    #   witness-stripped size = exactly 64 bytes
    #   full witness serialization = larger than 64 bytes
    
    csv512_script_pubkey = bytes([0x02, 0x00, 0x02, OP_CHECKSEQUENCEVERIFY])
    
    spending_input = ser_input(
        prev_txid_be_hex=funding_txid,
        vout=0,
        script_sig=b"",
        sequence=0xFFFFFFFF,
    )
    
    spending_output = ser_output(90_000, csv512_script_pubkey)
    
    spending_tx_stripped = (
        i32(2)
        + compact_size(1)
        + spending_input
        + compact_size(1)
        + spending_output
        + u32(0)
    )
    
    # P2WSH witness stack:
    #
    #   <secret> <witness_script>
    #
    spending_witness = (
        compact_size(2)
        + compact_size(len(secret))
        + secret
        + compact_size(len(witness_script))
        + witness_script
    )
    
    spending_tx_full = (
        i32(2)
        + b"\x00\x01"               # SegWit marker + flag
        + compact_size(1)
        + spending_input
        + compact_size(1)
        + spending_output
        + spending_witness
        + u32(0)
    )
    
    assert len(spending_tx_stripped) == 64
    assert csv512_script_pubkey.hex() == "020002b2"
    
    print("funding witnessScript:", witness_script.hex())
    print("funding scriptPubKey: ", funding_script_pubkey.hex())
    print("funding txid:         ", funding_txid)
    print("funding tx hex:       ", funding_tx.hex())
    print()
    print("spending output scriptPubKey:", csv512_script_pubkey.hex())
    print("spending stripped size:      ", len(spending_tx_stripped))
    print("spending full size:          ", len(spending_tx_full))
    print("spending txid:               ", hash256_be_hex(spending_tx_stripped))
    print("spending wtxid:              ", hash256_be_hex(spending_tx_full))
    print("spending tx stripped hex:    ", spending_tx_stripped.hex())
    print("spending tx full hex:        ", spending_tx_full.hex())
    ```
    
    On Saturday, May 2, 2026 at 8:56:25 AM UTC-7 Chris Stewart wrote:
    
    > I do concede your point that witness stripping isn't well understood by 
    > the general community. Here is a writeup I did for readers of the mailing 
    > list that may not understand what Jeremy is talking about the 
    > characteristics of a 64 byte transaction[0]. There is a big distinction 
    > between pre-segwit 64 byte transactions and segwit 64 byte transactions.
    >
    >
    > > 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)
    >
    > I find this confusing. Can you give 2 hex encoded transactions (funding 
    > transaction, spending transaction) that do this? regtest is fine, i can 
    > just decode locally.
    >
    > Splitting hairs semantically if understand the transactions you are 
    > proposing above, "donating" to a "future miner" i.e. sending money to *anyone 
    > (not a specific someone)* in the future that can mine a block - doesn't 
    > seem much different to me than "anyone can spend the funds". I'll await 
    > your transactions though in the case that I am missing something.
    >
    > [0] - 
    > https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73?u=chris_stewart_5
    >
    > On Fri, May 1, 2026 at 4: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 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+...@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=footer>
    >> .
    >>
    >
    
    -- 
    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/8a82e9d6-b013-4b7f-ba9f-f91f50b1bbe3n%40googlegroups.com.
    
    [-- Attachment #1.2: Type: text/html, Size: 19552 bytes --]
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

• * Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
    2026-05-01 21:14 [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses jeremy
                     ` (2 preceding siblings ...)
    2026-05-02 15:26 ` Chris Stewart
  @ 2026-05-06 11:10 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
    2026-05-06 21:35   ` jeremy
    3 siblings, 1 reply; 8+ messages in thread
  From: 'Antoine Poinsot' via Bitcoin Development Mailing List @ 2026-05-06 11:10 UTC (permalink / raw)
    To: jeremy; +Cc: Bitcoin Development Mailing List
  
  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.l.rubin@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+unsubscribe@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/A-Yiqh9r08Wd0V1KwMr7MlVObsiW3esWqySZZzm7aZBV3xBpL0qVJSpF07GfQBoq9YFpBLdlo0k2_tGU5CZ-i0_91MEketsaN8V4FpUnno0%3D%40protonmail.com.
  
  
  ^ permalink raw reply	[flat|nested] 8+ messages in thread

• • * Re: [bitcoindev] [BIP-0054] 64-Byte Transactions and Potential Legitimate Uses
      2026-05-06 11:10 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
    @ 2026-05-06 21:35   ` jeremy
      0 siblings, 0 replies; 8+ messages in thread
    From: jeremy @ 2026-05-06 21:35 UTC (permalink / raw)
      To: Bitcoin Development Mailing List
    
    
    [-- 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 --]
    
    ^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2026-05-14 14:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox