Ecrecover should handle chainId

This is a follow up to EIP-1344: Add chain id opcode

The purpose of EIP-1344 was to improve the security of signatures. Adding to that (or even independently of that) I would like to propose that ecrecover should be adjusted to handle EIP-155. This would allow even existing contracts to use signatures that cannot be replayed between chains.

Would love to hear your opinions.

cc the EIP-1344 people: @fubuloubu @wighawag @fulldecent


Great idea! Is the concept to change the Solidity implementation of ecrecover here to return a tuple of (address, chainId) for further verification?

1 Like

I think solidity needs to be updated anyways since it should accept something else for v (currently uint8 should probably be uint64)

Side note: changing the return value breaks backwards compatibility, also ecrecover will fail if the signature was created with an invalid chainId (and the current chainId can be checked with EIP-1344 :wink: ). But I see your point, that it might be interesting to know if a signature used a chain id.

Second side note: With EIP-1344 new contracts can implement this themselves by checking/adjusting the “v” before handing it over to the ecrecover function. (I would still love it, since it would provide additional security to existing contracts and also outside of EIP-712)

1 Like

I’m not sure why is there a change needed to the ecrecover built in method in Solidity? That is a low-level abstraction working off the precompile.

Handling of the chainid is (and should be) above this, e.g. the best place is high level “ec recover” libraries, such as the example I wrote or the widely used implementation in OpenZeppelin.

1 Like

And I think this issue may be better to be taken to