I have been investigating message signing using an Ethereum account, and have become somewhat bemused by the different signatures that I receive from different clients and different libraries.
I have attempted to get answers by contacting library/client creators directly but have gotten no definitive answers.
When I utilise jsonrpc to send off a signing (
web3.eth.sign) request to a Parity (1.6.6) backend, and a Geth (1.6.1) backend I get the following signatures back:
Now.. I do not have an in depth understanding of elliptical curve cryptography, but i can see here that Geth returns a RSV format signature, and Parity a VRS.
Question 1 Is there a consistent way of determining which format the signature is in (for backwards compatibility)?
Now.. I am trying to work with these signatures using the fantastic ethereumjs-util library.
ecsign method returns me a completely different signature:
I managed to recreate this signature from my Geth/Parity signatures by calling their
toRpcSig method with the r,s, and v values extracted from the Geth/Parity sigs.
Looking at the code it seems to concatenate
Buffer versions of these values and converts the result to a string.
Question 2 Why does ethereumjs-util do this?
The end result is that geth, Parity, and ethereumjs-util all return different signatures when signing an arbitrary message. Etherscan, and etherchain have signature verification libraries which believe the ethereumjs-util signature to be correct. This may well be because they use the library under the hood. If this is correct..
Question 3 Why do Geth and Parity both return incorrect message signatures?
There seems to be a lot of github discussions etc about appending prefixes to messages before signing them etc, yet seemingly no-one has addressed the issue of client inconsistencies in signing.. which in my opinion is pretty important.