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

ERC: Executable Signed Messages refunded by the contract #1077

Merged
merged 7 commits into from May 15, 2018

Conversation

Projects
None yet
5 participants
@alexvandesande
Copy link
Contributor

alexvandesande commented May 14, 2018

Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them is an emerging pattern being used in many projects. Standardizing a common format for them, as well as a way in which the user allows the transaction to be paid in tokens, gives app developers a lot of flexibility and can become the main way in which app users interact with the Blockchain.

alexvandesande and others added some commits May 14, 2018

ERC: Executable Signed Messages refunded by the contract
Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them is an emerging pattern being used in many projects. Standardizing a common format for them, as well as a way in which the user allows the transaction to be paid in tokens, gives app developers a lot of flexibility and can become the main way in which app users interact with the Blockchain.
@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented May 15, 2018

@alexvandesande I've edited the doc to fix the header formatting, but you still have build failures - please see the details message and fix.

@alexvandesande

This comment has been minimized.

Copy link
Contributor Author

alexvandesande commented May 15, 2018

Ok, it seems the issue was a dependency on #735 which doesn't exist in the new format. Removed it as it wasn't very important for the standard.

@alexvandesande

This comment has been minimized.

Copy link
Contributor Author

alexvandesande commented May 15, 2018

@Arachnid
The new build fails because it says 'replaces #877' which is in draft but not merged. Should I:

  1. remove the 877 reference (which unfortunately removes the information that this has been tried before)
  2. adapt 877 to the new format and have it merged (only for historical purposes, since I do not stand behind that one anymore)
@Arachnid

This comment has been minimized.

Copy link
Collaborator

Arachnid commented May 15, 2018

@alexvandesande It's up to you - either of those are fine.

@alexvandesande

This comment has been minimized.

Copy link
Contributor Author

alexvandesande commented May 15, 2018

It's ready to merge now. The other depends on this

@Arachnid Arachnid merged commit 7b56fab into ethereum:master May 15, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

Arachnid added a commit to Arachnid/EIPs that referenced this pull request Jul 19, 2018

ERC: Executable Signed Messages refunded by the contract (ethereum#1077)
* ERC: Executable Signed Messages refunded by the contract

Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them is an emerging pattern being used in many projects. Standardizing a common format for them, as well as a way in which the user allows the transaction to be paid in tokens, gives app developers a lot of flexibility and can become the main way in which app users interact with the Blockchain.

* Update eip-1077.md

* Update eip-1077.md

* Added uPort and Gnosis examples

* Swarm city

* change dependencies

* moves reference to 877
@shine2lay

This comment has been minimized.

Copy link

shine2lay commented Jul 30, 2018

I've implemented a version of this standard here: https://github.com/shine2lay/SmartContracts

@alexvandesande I have a question about gasEstimate function, can we just use web3.eth.estimateGas to get whether or not a transaction can be executed?

@PhABC

This comment has been minimized.

Copy link
Contributor

PhABC commented Aug 8, 2018

Hey @alexvandesande,

I am not convinced the extraHash argument is necessary in the first place and I think dataHash should not be a bytes32 hash, but arbitrary length bytes array. Because data would be of arbitrary length, extraData becomes a bit useless. I therefore suggest to remove extraHash and rename dataHash to data. I would also remove callPrefix since this should be part of the data byte array.

I think we should better detail what the gas refund process are. Currently, gasPrice specified by signer could be different from gasPrice used by executor, which provides an incentive for the executor to execute the transaction with the lowest gas price possible. This could be fine, but something I think we should mention. Using ERC20 tokens instead of ETH would need to adjust gasPrice properly, per specified by gasPrice in the signed message. It's not clear to me from the standard whether the gas refund is supposed to be profitable for the executor or not. Perhaps it would make more sense to calculate gasRefund and a bounty, both denominated in ETH or ERC20.

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Jan 14, 2019

Hi all,

This is a great initiative.

Few comments:

1) It seems that the current draft focuses on contract wallet/identity contract as the sole processors of such messages.

But such message could also work at the token level. An ERC20/ERC777 token contract could process such messages and perform the transaction without being an identity contract itself.

As such the from field should not be necessarily the contract as it is described in the current draft but could also be an external address.
To avoid replay attacks on other smart contracts, we can add a contract field that would serve the same purpose. I don't think we need callPrefix though.

2) There are several ambiguities that might make hard for users to know what they are signing.

The draft states :

How the contract interprets the intended action depends on its purpose. For instance a token contract can decide to implement it in a way that interprets all actions as token transfers, and uses the  value  to mean token value and  bytecode  as the data to pass to the recipient contract

This would be a nightmare for wallet UX. I think we should define unambiguously what each field represent so that a wallet receiving such message signature request could let the user know what is being transfered.

It also states :

Executes the signed message. Execution usually means that a contract will execute a  call  to the  to  address, with  value amount of ether and  data  as its data. But in some special cases, a token can decide instead to interpret it specifically as executing a  transferAndCall(to,from,data)  or the equivalent.

Again I think the standard would benefit in being less ambiguous and define exactly what the smart contract should do so wallet can inform the users accurately. If want different behavior, we add more signature format options

@wighawag

This comment has been minimized.

Copy link
Contributor

wighawag commented Jan 14, 2019

@PhABC
Not sure if you misunderstood but the dataHash is just used for the hash to be signed. The data sent as part of the transaction will contains all the bytes needed.

if we wanted to add extra options to the message format we would not necessarily want to pollute the data being used to call a function. Else this would require the contract processing the message to extract and remove that info from data before making the call to to hence the usefulness of extraHash

RegardingcallPrefix : if I understand correctly it is for the function of the identity contract itself that will perform the execution of the message, not for the function of to that will use the prefix contained in data
I guess it was added to prevent replay attack in the same contract in a different function. I don't think it is necessary though as such contract should not accept these messages through different pathways.

Good point about gasPrice, maybe the contract should refuse a call that use a smaller gasPrice that the one defined in the message.
Then for token based transaction, we should probably not reuse the same gasPrice field but add a tokenGasPrice field that is defined in term of gasPrice

This way the message signer is in control of the tx gasPrice (at least a minimum)

@wighawag wighawag referenced this pull request Mar 2, 2019

Open

ERC: Key Manager #734

@wighawag wighawag referenced this pull request Mar 9, 2019

Open

ERC: Proxy Account #725

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.