1

Is there any reason ecrecover() takes the (v, r, s) signature parameters instead of the full signature, given that these can be easily computed inside the function itself?

I am asking because developers usually need to compute these parameters from the full signature each time they need to use ecrecover(), which seems like an unnecessary repetitive process that could've been mitigated had ecrecover() took the full signature instead.

0

Signatures typically use v to store the signature and r,s to store the hashed data. I agree that using ecrecover adds extra complexity and by adding approve/transferFrom we get a bit of anonymity because we allow a 3rd party to extract tokens from our balance for a fee, usually in WETH or something similar.

People say that if we use signatures we become anonymous which is totally false since nothing is truly hidden on ethereum. More on that topic you can find out from here: https://medium.com/swlh/ethereum-aint-hiding-your-secrets-703e89088937

Signatures are more broadly used to identify the user that use Metamask. We make our user sign something that either contains a source of random entropy or has already been secretly hashed with our private key and provide after that we check who the author of the new signature is and provide a temporarily session using ecrecover.

The exact approach can be found here: https://programtheblockchain.com/posts/2018/02/17/signing-and-verifying-messages-in-ethereum/

Also if you want a better & more detailed approach to signatures you can find our more by looking at how DreamTeamToken made their implementation here: https://etherscan.io/address/0x82f4ded9cec9b5750fbff5c2185aee35afc16587#code It should be easy to update to Solidity 0.5 , if you have any struggles regarding this please let me know.

0

v, r, s are parameters in Ethereum transactions. An Ethereum transaction is the serialization of these values. Ethereum libraries will and should have methods to serialize and deserialize transactions so finding the v, r, s values should be no harder than calling a deserialize/decode function on a signed Ethereum transaction, you shouldn't have to calculate these values yourself.

You should note that what we call a signature is actually 256 bits and is the combination of the r and s field. The v field only contains one bit of information about the signature and makes it possible to derive the public associated with the signature -- such that you don't need to include that in the signed transaction. Understanding Ethereum signatures

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.