Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep referencing using hashes of complete transactions (including signatures), while the OP_CHECKAWESOMESIG looks up the previous transaction (which we already need to do anyway in order to insert the prevOut pubkeyScript), normalizes the prevout and calculates its normalized transaction ID. It then inserts the normalized transaction IDs in the OutPoint before calculating its own hash which is then signed. Is that correct so far?
Let me try to summarize the discussion so far:
I think we have consensus that transaction malleability needs to be addressed, and normalized transaction IDs seem to be the way to go forward.
The discussion now is how to use normalized transaction IDs and we have two approaches to implement them:
- OP_CHECKAWESOMESIG which continues to use the current hashes to reference a specific signed instance of a class of semantically identical transactions. Internally only the semantic class is enforced. Transactions can be fixed to reference the correct signed instance if the transaction has been changed along the way.
- The second proposal advocates using the normalized transaction IDs directly in the transactions, requiring no further intervention to fix an eventually malleated transaction.
Both approaches have their own advantages and problems:
OP_CHECKAWESOMESIG is a soft-fork which makes it somewhat less problematic to roll-out and does not break existing software. The normalized transaction ID can be computed on the fly (possibly increasing lookup times) or stored alongside the UTXO (increasing storage needs). If the normalized transaction IDs really need to be recomputed down to the coinbase then the increased storage is the only option, and would add 32 byte to every transaction metadata in the UTXO.
My proposal is harder to migrate to, as it requires a hardfork, and will require more storage (64 byte raw data for a normalized to legacy transaction ID) for every transaction in the UTXO set. At 6 million distinct transactions which unspent outputs this boils down to 384 MB (though this may change in future by introducing an aggregation strategy or fragment further). Some of that space may be reclaimed. There is absolutely no interaction required to fix up transactions if a dependency has been malleated, since we address a semantic class, not the specific instance. We limit the use of normalized transaction IDs to the OutPoint in transactions, since there we want to reference the semantic class not the actual signed instance. At protocol message level (inv, getdata) and blocks we continue to use the legacy ID. This is not as nice as having one ID for every transaction that is used everywhere.
Both solutions solve malleability, just with different tradeoffs.
I don't see them as mutually exclusive, if we adopt the OP_CHECKAWESOMESIG as short term fix, that can be rolled out and applied, then my proposal can be seen as long-term goal that is semantically cleaner and easier to implement.
Personally I think hard-forks shouldn't be the dreaded boogeyman everybody makes them out to be, we have never really tested rolling out a hardfork and they might just turn out to be possible. I don't thing we loose anything by attempting this, except maybe reduce the urgency to apply some perfect future thing.
Regards,
Christian