Why does txID generation consider signatures?

Question

I've been reading a lot about transaction malleability, and noticed that the only way to achieve it is by altering the transaction signature/s.

Why does the protocol even consider the signature in the payload for SHA256? The protocol should only consider inputs and outputs as they are, ignore the signatures. txID should only be altered by altering inputs or outputs, thats it. If anybody would like to alter any input or output to change the txID, he'll need to change signatures as well.

In other words, if you don't consider signatures while generating the txID, transaction malleability would be impossible.

Please, let me know if I'm missing something here.

Answer 1

If the signature was not part of the transaction protected by the hash, then you could have two different transactions, one valid and one invalid, with the same transaction ID. The primary purpose of the transaction ID is to permit agreement on whether a transaction is valid or not. So excluding the signatures from the hash would make transaction IDs unsuitable for their primary purpose.

One proposal for dealing with malleability attacks it to have a second transaction ID just for the purpose of defeating such attacks. This transaction ID wouldn't cover the signatures. But it wouldn't be suitable for checking transaction validity, forcing a system in which there are two types of transaction identifiers.

Answer 2

I'll have to read up on Txn malleability but I do know that without actually signing the txn there's no way to prove ownership of the public key being spent.

Signing the txn will always give a different signature (unless the k value is kept constant which was the source of the August 2013 Android bug). Ecdsa simply validates that the txn is signed with the correct key. A hash of the inputs and outputs is what's signed. So yes, that shouldn't change, but because the ECDSA signature does change the protocol is simply validating the signature.