I think the answer is yes no.
The smallest possible non-coinbase transaction is 61 bytes:
It is a transaction that spends an OP_TRUE anyonecanspend output and creates 1 OP_TRUE anyonecanspend output.
From https://bitcoin.stackexchange.com/a/54682/4948
Though I think it’s 60 bytes? It doesn’t matter for the conclusion.
This transaction T consists of:
- 4 bytes version
- 1 byte input count (for one input)
- 36 byte prevout (
A) - 1 byte to indicate an empty
scriptSig(S) - 4 byte sequence number
- 1 byte output count
- 8 byte sats spent by first output
- 1 byte scriptPubKey length
- 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) as well as the destination B to a maximum of 4 bytes, combined. Which confirms there is no possible secure B (>= 20 byte).
Additionally, BIP66 constrains signatures to at 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 also means we can enumerate all possible S and determine if they’re malleable.
Since the scriptSig can’t contain a signature, the answer seems to be trivially yes. For example an empty scriptSig can be malleated to OP_TRUE to add one byte to the transaction size.
Since we can always malleate the scriptSig we don’t have to consider the destination B.
Update 2025-03-29: as Vojtěch points out:
not every 64-byte transaction can be malleated by a third party. If a transaction spends a SegWit output (e.g. P2WPKH), the input can have a signature in the witness and it won’t count towards the 64 byte target, preventing third parties from changing the output script or attaching more inputs.
such a transaction can only have a 4-byte output script, which is necessarily spendable either by everyone (e.g. anchor output) or no one (e.g. OP_RETURN).
But So next we could enumerate all possible destinations B. Since no 4 byte destination can securely hold funds, the only “divert” concern is whether one can malleate any anyonecanspend into a burn and vice versa.
I think the answer to this question is yes, since there’s no signature committing to the transaction, you can swap e.g. OP_TRUE for OP_RETURN. The point being to emphasise there is no safe 64 byte transaction even under this low bar of “safe”.
Update 2025-03-28: there is no signature in the scriptSig, but there could be one in the witness which doesn’t count toward the 64 byte rule. If the witness signature uses SIGHASH_ALL then the output can’t be modified and no input / output pair can be added to modify the size. Witness malleation wouldn’t help here either.
Update 2025-03-28: bonus question: could any of the current proposed covenant op codes (further) restrict B and not allow new outputs?