bitcoin-dev

[BIP] Normalized transaction IDs

[BIP] Normalized transaction IDs

Original Postby Danny Thorpe

Posted on: October 21, 2015 18:22 UTC

The discussion on the bitcoin-dev mailing list revolved around the issue of transaction malleability.

A concern was raised about signers modifying the order of inputs or changing outputs when re-signing a transaction which already has dependent child transactions spending its outputs. This was deemed a different hazard than a third party maliciously modifying a transaction in the mempool by twiddling opcodes in the signature scripts. The former hazard was considered as more of an internal affair and the latter as an external threat beyond the control of the transaction writer. While canonical ordering for inputs and outputs might be useful in some cases, there are also use cases where the relative positions of inputs and outputs are significant, and reordering would change the semantics of the transaction. SIGHASH_SINGLE and Open Asset colored coins are examples that make an association between an input index and an output index. Therefore, it was suggested to keep canonical ordering separate from the normalized transaction ID proposal, with the focus on normalized transaction IDs providing an immediate benefit against the hazard of third-party manipulation of transactions in the mempool, even without canonical ordering. Luke Dashjr pointed out that if multiple signers were involved in a transaction, then modifying the order of inputs and changing outputs would invalidate the signatures of other signers. However, Christian Decker suggested that the other signers could re-sign with the modified version, and this form of malleability should also be addressed in the BIP proposal.