<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2014-12-15T20:00:13.073Z
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
CC BY-SA 3.0
2014-12-16T00:24:24.897Z
@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.
David Schwartz
CC BY-SA 3.0
2014-12-16T04:13:41.743Z
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
CC BY-SA 3.0
2014-12-18T02:13:51.717Z
@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.
David Schwartz
CC BY-SA 3.0
2014-12-19T01:36:24.023Z
Thats the point, Doesn't matter if transactions are different as long as both do exactly the same thing.
masize
CC BY-SA 3.0
2014-12-19T05:56:35.480Z
@masize It does matter because some could have invalid signatures. A transaction with an invalid signature doesn't do anything.
David Schwartz
CC BY-SA 3.0
2014-12-19T15:19:23.020Z
Why would anyone have a transaction with invalid signatures?
The client ALWAYS checks the signatures, the txID is just a hash. The only thing that could happen is that you could relay the same transaction to the network with different signatures, but BOTH valids, and nodes would have the same transaction with different signatures, but ALWAYS valid, as the client ALWAYS checks this, but who cares, as long as they are valid and do the same thing, there's no problem at all.
masize
CC BY-SA 3.0
2014-12-19T18:18:33.053Z
@masize There's a huge problem for anyone who ever needs to store the transaction and index it by hash. Essentially, you're solving the transaction malleability problem by making transaction IDs useless as authoritative keys.
David Schwartz
CC BY-SA 3.0
2014-12-15T15:48:48.250Z
2014-12-15T15:48:48.250Z
David Schwartz
<p>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. </p>

<p>Signing the txn will always give a different signature (unless the <em>k value</em> 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. </p>

CC BY-SA 3.0
2014-12-13T15:36:02.973Z
Thanks for the response but Transaction Malleability has nothing to do with ownership proof.
masize
CC BY-SA 3.0
2014-12-13T04:48:28.470Z
2014-12-13T04:48:28.470Z
Wizard Of Ozzie
<p>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.</p>

<p>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.</p>

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

<p>Please, let me know if I'm missing something here.</p>

<transactions><signature><transaction-malleability><transaction-id>
Why does txID generation consider signatures?
masize
# Why does txID generation consider signatures?

(Asked by: username_0 on 2014-12-12)

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.

**Tags:** transactions, signature, transaction-malleability, transaction-id


---

## 2 answers

### Answer by username_1 on 2014-12-15. Score: 4

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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: @username_0 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.  
> **username_0**: 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.  
> **username_1**: @username_0 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.  
> **username_0**: Thats the point, Doesn't matter if transactions are different as long as both do exactly the same thing.  
> **username_1**: @username_0 It does matter because some could have invalid signatures. A transaction with an invalid signature doesn't do anything.  
> **username_0**: Why would anyone have a transaction with invalid signatures? The client ALWAYS checks the signatures, the txID is just a hash. The only thing that could happen is that you could relay the same transaction to the network with different signatures, but BOTH valids, and nodes would have the same transaction with different signatures, but ALWAYS valid, as the client ALWAYS checks this, but who cares, as long as they are valid and do the same thing, there's no problem at all.  
> **username_1**: @username_0 There's a huge problem for anyone who ever needs to store the transaction and index it by hash. Essentially, you're solving the transaction malleability problem by making transaction IDs useless as authoritative keys.  

---

### Answer by username_2 on 2014-12-13. Score: 0

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.

> **Comments:**
> **username_0**: Thanks for the response but Transaction Malleability has nothing to do with ownership proof.  

---

