-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simpler signing and verifying procedure #79
Comments
Why do you want to mix hashing into ecrecover? Possible alternatives:
(I am using |
Because of simplicity. I think most use cases involves verifying a message that is known to the verifier, and so since hashing will always be a part of the procedure, I think it should be mixed in. But keeping backwards compatibility in mind, your approach could be a bit more elegant elegant. |
I think It is used in btcrelay to check Bitcoin transaction signatures and in Quroum to check Bitcoin signed messages. Those obviously require different hashing and encapsulation methods. If at all possible I would not include hashing as a parameter in the precompiled contract. Having a more user friendly implementation in Solidity with appropriate helpers seems like a good solution. While speaking of this I am not entirely happy that |
Does this help crypto abstraction? |
With payment channel like solutions I think it is, but you are right that with the use in BTCRelay and similair scenarios bundling hashing with ecrecover doesn't make much sense.
I agree. Essentially what I want is that developers shouldn't have to worry about ECDSA values, they just need a signature. |
@MrChico since we have assembly support in Solidity, this is a piece of cake: https://gist.github.com/axic/5b33912c6f61ae6fd96d6c4a47afde6d |
Great solution @axic! |
@MrChico can you point me to the issue where that change was discussed? Other implementations, such as testrpc should follow that too. |
@axic |
Is there any way to verify a signature with Web3? |
@anrodon not yet |
Thanks @MrChico, updated the gist to support both. |
I still agree that this simplified function should be part of Solidity. If you look into signing messages for the first time, the current way and documentation isn't easy enough (http://solidity.readthedocs.io/en/latest/units-and-global-variables.html?highlight=ecrecover#mathematical-and-cryptographic-functions) |
@anrodon, you might want to check https://web3js.readthedocs.io/en/1.0/web3-eth-personal.html#ecrecover documentation. It says we can use web3.personal.ecrecover function. |
@MrChico doc says web.eth.sign returns string |
@dhaileytaha check out the library contract by @axic https://gist.github.com/axic/5b33912c6f61ae6fd96d6c4a47afde6d. |
@MrChico Does closing this issue mean it's been decided not to include these helpers into solidity itself (as a precompiled contract or whatever)? I can find a lot of example implementations on the internet, but it'd be really good to have a canonical version sanctioned by the ethereum development team. |
…tokenid-syntax Editorial/caip19 eip155 tokenid syntax
To make the life of developers on ethereum, many encountering the tools of cryptography for the first time, the ECDSA for signing and verifying a message should be as simple as possible (but no simpler).
I believe that the current procedure is more complicated than necessary, which gives rise to confusion:
http://ethereum.stackexchange.com/questions/1777/workflow-on-signing-a-string-with-private-key-followed-by-signature-verification
http://ethereum.stackexchange.com/questions/710/how-can-i-verify-a-cryptographic-signature-that-was-produced-by-an-ethereum-addr/718#
I propose that the intermediate steps of hashing the message should be removed, and that developers shouldn't have to deal with ECDSA values r, s and v at all, just a 65 byte signature.
The procedure would then be as simple as:
With web3 or in the javascript console:
Which could then be directly used in a solidity contract as:
If there are use cases where one wants to sign a message that has already been hashed, then this option could be passed as an option to the functions, like:
signature = eth_sign(address, hash, {hashed: true})
orecrecover(hash, signature, {hashed: true})
A prerequisite of this is of course that all clients return the signature in the same format, so first this issue needs to be addressed.
The text was updated successfully, but these errors were encountered: