Quote from: thecomputerscientist on February 13, 2014, 08:51:28 AM

Quote from: uminatsu on February 13, 2014, 07:22:49 AM

Quote from: thecomputerscientist on February 12, 2014, 11:16:06 AM

The final signature by itself is malleable, because for every ECDSA signature (r,s), the signature (r, -s (mod N)) is also a valid signature (of the same message.)

This can be solved by requiring that "s" always be an even number. Since N is odd, only one signature is accepted as canonical.

Correct. I found a summary here:

https://gist.github.com/sipa/8907691

If I understand this correctly, (1)-(2) in this list should prevent evil* malleability. (It's only interesting to protect the signature itself, as all the other stuff cannot be modified as that would invalidate the signature.) Can someone confirm this?

*evil = eavesdropping and then modify transaction by someone who does not have access to private key

Ok, got the answers now. So there are two sources of malleability; the signature itself and the scriptSig (there's a scriptSig per input). The scriptSig is not (and cannot be) part of the signature, so you can come up with all kinds of malleability issues here. Therefore, my arguments above are applicable to scriptSig, but it is very important that you can prove you have the "smallest" scriptSig because otherwise an attacker would be able to exploit that. I talked to gmaxwell and (2)-(4) are already deployed since a while back. (5) is checked in but not shipped. So (1) and (6) remain. They are slowly closing the malleability gaps, but it will take some time. Meanwhile, if you're a wallet provider, you should just ensure that malleability is a possibility and write code that is robust enough, i.e. look at the outputs to see if a transaction got through; never use the transaction hash for tracking. 7-8 are not big issues, because they are under the original tx broadcaster's control.