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.

2 Answers 2


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.

  • You are right, you could have 2 transactions with the same ID, one valid and the other one invalid. So the client would discard the invalid, don't even relaying it to the network and keep the valid one on the pool. The client already works this way, so the only thing that must be changed is the way transactionID is generated, signatures shouldn't be included in the SHA256, because the signatures are already checked later.
    – masize
    Commented Dec 15, 2014 at 20:00
  • @masize I think you're missing the point. If you changed the way the transaction ID is generated, the client would fail horribly. It might refuse to relay a transaction because it knows that transaction is invalid even though it's actually valid. Attacks on the network would be possible where you corrupt a signature, causing nodes to "know" that the transaction with that ID is invalid. Commented Dec 16, 2014 at 0:24
  • please let me know what I'm getting wrong. The steps are as follows : Check transaction ID hash => Check unspent outputs => Check valid signatures => Relay tx to the network. If any of those fail, transaction would be discarded, txID is not tagged or cached as invalid forever, just this transaction as received is invalid. The current client does all this procedure. TransactionID generation give no assurance on valid signature, client must check those anyway.
    – masize
    Commented Dec 16, 2014 at 4:13
  • @masize How could you ever know if you had a correct copy of a particular transaction? Currently, you can hash it and compare it to the transaction ID. Commented Dec 18, 2014 at 2:13
  • Thats the point, Doesn't matter if transactions are different as long as both do exactly the same thing.
    – masize
    Commented Dec 19, 2014 at 1:36

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.

  • Thanks for the response but Transaction Malleability has nothing to do with ownership proof.
    – masize
    Commented Dec 13, 2014 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.