I believe the reply is sure no.
The smallest attainable non-coinbase transaction is 61 bytes:
It’s a transaction that spends an OP_TRUE anyonecanspend output and creates 1 OP_TRUE anyonecanspend output.
From https://bitcoin.stackexchange.com/a/54682/4948
Although I believe it is 60 bytes? It would not matter for the conclusion.
This transaction T consists of:
- 4 bytes model
- 1 byte enter rely (for one enter)
- 36 byte prevout (
A) - 1 byte to point an empty
scriptSig(S) - 4 byte sequence quantity
- 1 byte output rely
- 8 byte sats spent by first output
- 1 byte scriptPubKey size
- 0 byte: empty scriptPubKey (
B) - 4 byte: lock time
From https://developer.bitcoin.org/reference/transactions.html#raw-transaction-format
That constrains the scriptSig (S) in addition to the vacation spot B to a most of 4 bytes, mixed. Which confirms there is no such thing as a attainable safe B (>= 20 byte).
Moreover, BIP66 constrains signatures to at the least 9 bytes: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-h-64-byte-pre-segwit-transactions-cannot-contain-a-digital-signature-in-the-scriptsig-3
It additionally means we are able to enumerate all attainable S and decide in the event that they’re malleable.
For the reason that scriptSig cannot include a signature, the reply appears to be trivially sure. For instance an empty scriptSig will be malleated to OP_TRUE so as to add one byte to the transaction dimension.
Since we are able to at all times malleate the scriptSig we do not have to contemplate the vacation spot B.
Replace 2025-03-29: as Vojtěch factors out:
not each 64-byte transaction will be malleated by a 3rd occasion. If a transaction spends a SegWit output (e.g. P2WPKH), the enter can have a signature within the witness and it will not rely in the direction of the 64 byte goal, stopping third events from altering the output script or attaching extra inputs.
such a transaction can solely have a 4-byte output script, which is essentially spendable both by everybody (e.g. anchor output) or nobody (e.g. OP_RETURN).
However So subsequent we might enumerate all attainable locations B. Since no 4 byte vacation spot can securely maintain funds, the one “divert” concern is whether or not one can malleate any anyonecanspend right into a burn and vice versa.
I believe the reply to this query is sure, since there isn’t any signature committing to the transaction, you’ll be able to swap e.g. OP_TRUE for OP_RETURN. The purpose being to emphasize there is no such thing as a secure 64 byte transaction even below this low bar of “secure”.
Replace 2025-03-28: there is no such thing as a signature within the scriptSig, however there might be one within the witness which does not rely towards the 64 byte rule. If the witness signature makes use of SIGHASH_ALL then the output cannot be modified and no enter / output pair will be added to change the scale. Witness malleation would not assist right here both.
Replace 2025-03-28: bonus query: might any of the present proposed covenant op codes (additional) prohibit B and never enable new outputs?