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.