4

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.

masize
  • 61
  • 4

2 Answers2

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.

David Schwartz
  • 51,308
  • 6
  • 106
  • 177
  • 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 Dec 15 '14 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. – David Schwartz Dec 16 '14 at 00: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 Dec 16 '14 at 04: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. – David Schwartz Dec 18 '14 at 02:13
  • Thats the point, Doesn't matter if transactions are different as long as both do exactly the same thing. – masize Dec 19 '14 at 01:36
  • @masize It does matter because some could have invalid signatures. A transaction with an invalid signature doesn't do anything. – David Schwartz Dec 19 '14 at 05:56
  • 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 Dec 19 '14 at 15:19
  • @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 Dec 19 '14 at 18:18
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.

Wizard Of Ozzie
  • 5,268
  • 4
  • 30
  • 63
  • Thanks for the response but Transaction Malleability has nothing to do with ownership proof. – masize Dec 13 '14 at 15:36