4
2
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.
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 – 2014-12-15T20:00:13.073
@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 – 2014-12-16T00:24:24.897
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 – 2014-12-16T04:13:41.743
@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 – 2014-12-18T02:13:51.717
Thats the point, Doesn't matter if transactions are different as long as both do exactly the same thing. – masize – 2014-12-19T01:36:24.023
@masize It does matter because some could have invalid signatures. A transaction with an invalid signature doesn't do anything. – David Schwartz – 2014-12-19T05:56:35.480
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 – 2014-12-19T15:19:23.020
@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 – 2014-12-19T18:18:33.053