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.