Transaction sizes could be significantly reduced if the same signature could be used to validate multiple inputs.
Consider a transaction with hundreds of inputs – right now, the inputs section of that transaction will cost at least
input count * 100 to 108 bytes (in the best case, signatures are 65 bytes and public keys are 33 bytes, + 2 bytes of push ops). With TxInt supported in unlocking bytecode, that would be reduced to around
input count * 3 to 11 bytes, saving many KBs for large transactions.
This has some overlap with the MuSig idea, which recently came up in the Transaction Introspection Telegram group. Background:
There may now be a more promising strategy for implementing the MuSig idea than adding it as a new TX field: we could allow sibling inputs to pull signatures from each other’s stack using transaction introspection opcodes. That would even allow transactions to have multiple MuSigs, e.g. if there are two distinct aggregate public keys and many outputs for each need to be spent in the same transaction. […]
So some inputs could be as simple as e.g.
<N> OP_INPUTBYTECODE, and the unlocking bytecode of input
<AggregateSig> <AggregatePubKey>. That would allow most inputs to have only 2 bytes, and the same signature(s) to be used by an unlimited number of inputs. […]
One non-obvious issue: anytime we allow a “non-constant” operation in an unlocking script, we introduce a malleability vector. An active third party can intercept the transaction and replace it with a TX where all inputs are “pre-computed” – the evaluated result on the stack is pushed directly rather than using the original unlocking bytecode. […]
In this particular case, the “precomputation malleability” isn’t as acute because the larger unlocking bytecode for the malleated transaction would make the relative fee rate lower than the original transaction. So if most of the network uses the 1 satoshi-per-byte heuristic, the malleated transactions would never be accepted. But that also seems insufficient to rely on. (E.g. it’s conceivable that some transactions could accidentally be malleable – someone can scan incoming transactions for snippets of repeated unlocking bytecode and grief them by broadcasting a more byte-efficient introspection opcode-based version. Wouldn’t be bad for the network, but would modify the eventual TXID and possibly disrupt the sending wallet.) […]
I’m wondering if this would be best solved by a new signing serialization/sighash type which also includes non-exempt unlocking bytecode (where exemption is somehow indicated by the presence of the sighash/type flag in each other input… the simplest option would be to only exclude the current input, which in practice would limit transactions to only one input using this sighash/type flag)
I’m going to think about this more (probably along the vein of a new sighash/signing serialization type), but if anyone has any ideas for resolving the malleability question, please share!