Skip to content
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

Update EIP-191: Improve Comprehensibility #5804

Merged
merged 5 commits into from
Nov 25, 2022

Conversation

YamenMerhi
Copy link
Contributor

What does this PR introduce?

  • Updating the example to be more comprehensive + more updated.
  • Simplifying the EIP191 Standard, by providing more explanation of the different versions.
    • Re-ordering the text so we start by:
      - The formula for the standard
      - Why we have 0x19
      - What are the different bytes version we have
    • Explicitly mentioning that E is version 0x45and thereum Signed Message:\n" + len(message) is version specific data.

@github-actions github-actions bot added c-update Modifies an existing proposal s-final This EIP is Final t-erc labels Oct 19, 2022
@eth-bot
Copy link
Collaborator

eth-bot commented Oct 19, 2022

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):


(fail) eip-191.md

classification
updateEIP
  • eip-191.md is in state final at the head commit, not draft or last call or review; an EIP editor needs to approve this change
  • This PR requires review from one of [@axic, @SamWilsn, @Pandapip1]
  • eip-191.md requires approval from one of (@holiman, @Arachnid)

@Pandapip1 Pandapip1 added the a-review Waiting on author to review label Oct 19, 2022
@Pandapip1 Pandapip1 changed the title improve EIP191 Standard Update EIP-191: Improve Comprehensibility Oct 19, 2022
@YamenMerhi
Copy link
Contributor Author

I know this is an old standard and missing some sections, I am happy to add them.
Also was wondering if we should mention in a Security Consideration section that it's advised to use 0x00 for any execution based on signature as people could be easily tricked to sign normal 0x45 messages as it's normally used for SIWE and for offchain verification

Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, aside from one nitpick

EIPS/eip-191.md Outdated Show resolved Hide resolved
holiman
holiman previously approved these changes Oct 27, 2022
Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Pandapip1
Pandapip1 previously approved these changes Oct 27, 2022
@Pandapip1 Pandapip1 added this to the Manual Merge Queue milestone Oct 27, 2022
@eth-bot eth-bot enabled auto-merge (squash) October 27, 2022 13:06
eth-bot
eth-bot previously approved these changes Oct 27, 2022
EIPS/eip-191.md Outdated Show resolved Hide resolved
EIPS/eip-191.md Outdated Show resolved Hide resolved
EIPS/eip-191.md Outdated
Comment on lines 66 to 102
function submitTransactionPreSigned(address destination, uint value, bytes data, uint nonce, uint8 v, bytes32 r, bytes32 s)
public
returns (bytes32 transactionHash)
{
function signatureBasedExecution(address target, uint256 nonce, bytes memory payload, bytes memory signature)
public payable {

// Arguments when calculating hash to validate
// 1: byte(0x19) - the initial 0x19 byte
// 2: byte(0) - the version byte
// 3: this - the validator address
// 4-7 : Application specific data
transactionHash = keccak256(abi.encodePacked(byte(0x19),byte(0),address(this),destination, value, data, nonce));
sender = ecrecover(transactionHash, v, r, s);
// ...
// 3: address(this) - the validator address
// 4-6 : Application specific data

bytes32 hash = keccak256(abi.encodePacked(byte(0x19), byte(0), address(this), msg.value, nonce, payload));

// recovering the signer from the hash and the signature
addressRecovered = ECDSA.recover(hash, signature);

// logic of the wallet
if (addressRecovered == owner) executeOnTarget(target,payload);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not the minimal change required to fix errata. Since this is a final EIP, we only allow clarifications and correcting errors. The minimal change would likely be just changing the 7 to a 6, unless there's something else I missed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point @SamWilsn , I will revert the OZ integration and keep plain ecrecover but what if the example is not clear ? Just for the sake of backwards compatibility we leave it like this ? (Knowing that no one will use this code snippet)

The name of the function IMO is not perfect, the same for the naming of variables, as it's not a TransactionPreSigned or a transactionHash, it's a signed message and hash of a signed message. This whole standard was created to find a standard way to differentiate between signed transactions and signed messages and here the naming is super confusing.

Also the example show how to sign but doesn't give info about what's the possibilities when signing the message. It's just like showing someone a fish hook but not teaching them how to start fishing 😄

I would find a balance between your suggestions and mine like that:

  • Reverted the OZ integration
  • Made the new logic as a comment just to emphasize on how this signed message could be used
  • Made change to the naming of the function and variables
function signatureBasedExecution(address target, uint256 nonce, bytes memory payload, uint8 v, bytes32 r, bytes32 s) public payable {
        
    // Arguments when calculating hash to validate
    // 1: byte(0x19) - the initial 0x19 byte
    // 2: byte(0) - the version byte
    // 3: address(this) - the validator address
    // 4-6 : Application specific data

    bytes32 hash = keccak256(abi.encodePacked(byte(0x19), byte(0), address(this), msg.value, nonce, payload));

    // recovering the signer from the hash and the signature
    addressRecovered = ecrecover(hash, v, r, s);
   
    // logic of the wallet
    // if (addressRecovered == owner) executeOnTarget(target, payload);
}

Please let me know what do you think 😄 🙏

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can go ahead and make this change to the PR. This version is a smaller change.

@Cryptonics1

This comment was marked as spam.

@Pandapip1 Pandapip1 removed this from the Manual Merge Queue milestone Nov 5, 2022
auto-merge was automatically disabled November 15, 2022 12:39

Head branch was pushed to by a user without write access

Co-authored-by: Pandapip1 <[email protected]>
@YamenMerhi YamenMerhi dismissed stale reviews from eth-bot, Pandapip1, and holiman via 0f462d1 November 15, 2022 12:39
@YamenMerhi
Copy link
Contributor Author

@SamWilsn @Pandapip1 Applied the changes 👍

Copy link
Member

@Pandapip1 Pandapip1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On line 39, ERC needs to be changed to EIP. On line 35, the external link needs to be removed.

@YamenMerhi
Copy link
Contributor Author

@Pandapip1 Done 👍

Copy link
Member

@Pandapip1 Pandapip1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 from me. Will need manual merge.

@Pandapip1 Pandapip1 added this to the Manual Merge Queue milestone Nov 16, 2022
#### Version `0x00`

```
0x19 <0x00> <intended validator address> <data to sign>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, I must be missing something here, are we adding the <0x00> <intended validator address> to the original EIP-191?

Copy link
Contributor Author

@YamenMerhi YamenMerhi Nov 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xinbenlv The version 0x00 was always there in the standard from the start, but it was not explained very well, and that's one of the purposes of the PR


#### Version `0x01`

The version `0x01` is for structured data as defined in [EIP-712]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

QQ: Should we mention anything about the EIP-712 "domain" besides the "structured data" here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@xinbenlv According to @holiman the co-author of the EIP191 standard:

I'd prefer to leave the definition fully to EIP-712. So simply say:
The version 0x01 is for structured data as defined in EIP-712

@SamWilsn SamWilsn merged commit b26436b into ethereum:master Nov 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-review Waiting on author to review c-update Modifies an existing proposal s-final This EIP is Final t-erc
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants