EIP-2612: 712-signed token approvals

[MrChico]

This EIP is now final. Discussions about final EIPs should be on https://ethereum-magicians.org/

This is a place for discussing #2612, which proposes an additional method permit for making approvals by way of signed messages rather than direct transactions

[maurelian]

IMO the 'security considerations' section should mention the front running attack that can occur when an allowance is reduced, either by approve or the new permit function. I don't think this proposal changes the risk or possible mitigations in any way, but I haven't thought hard about it.

If you have a strong desire to do some bike shedding, you could even suggest a specific mitigation for it. 😝

[Nipol]

I was looking forward to talking about this. I'd like to talk about the need for a "deadline"

What aspects of Tx Relayer do we need to take into account "deadline"? The Tx Relayer may have a response that causes tx while setting tx fee low. or no response.

And when a user signs for an interface, it requires more information. or more knowledge. Is usability not compromised? and more complexity for Tx Relayer.

So I think the deadline is unnecessary. 🤔

[maurelian]

I like deadline, as it solves the problem of worrying about all the approvals one has floating out in the world.
That said, I am sympathetic to the argument that it is inconsistent with the existing approve interface.

[MrChico]

Thanks @maurelian, added a comment about the approval front running attack.
@Nipol The deadline parameter is a way to mitigate the free option that the relaying party gets when receiving a signed message (it is just a deadline for the Permit itself, not for the approval so I don't think it solves the problem of random tokens being given allowance). In cases where the free option is not a concern, deadline can simply be set to uint(-1), so it should be seen as an optional parameter

[MrChico]

Actually @maurelian I was just made aware of the xDai staking token implementation of permit which I think does what exactly what you are alluding to here. It shares the same ABI as Dai and Chai, but not the same semantics. I guess we better document all three flavors in the ERC

[Nipol]

In terms of "Free Options," I think deadline has sufficient requirements.

But in terms of EIP-712, deadline is not convincing.
deadline is a difficult option for most signer to understand. at now, no example of an interface receiving a deadline value exists.

We can't show you the "Free Options" article every time ask for a signature. If we cannot effectively explain deadline to the signer and Tx Relayer, uint256(-1) will be used in most cases.

Furthermore, deadline is a consideration that does not appear in the EIP-712 specification. I think it does not have to appear as an exception in Permit.

If all of these signatures necessary a "deadline" option, if all of EIP-712 signatures have the same security level, I think it's better to update the EIP-712 specification. 🙂

What is the best option? What do you think?

[MrChico]

We can't show you the "Free Options" article every time ask for a signature. If we cannot effectively explain deadline to the signer and Tx Relayer, uint256(-1) will be used in most cases.

I'm perfectly happy with uint(-1) being used in most cases.

deadline is a difficult option for most signer to understand. at now, no example of an interface receiving a deadline value exists.

There are already interfaces which deal with deadline, uniswap being one of them:

or, for Permit https://stablecoin.services automatically sets deadline 4 minutes into the future.

I can agree with your point that it may a difficult point for users to understand, and one that may require some EIP-712 tweaking to improve. Another ux improving solution could also be to introduce Date as a type to 712, to improve how it is rendered to the user.

I do think that these options fall outside the scope of this ERC though, especially since this in some sense more of a descriptive erc than a prescriptive erc; I am highlighting what has been implemented and the motivations behind it. We can certainly make tweaks in new versions, but I am mainly interested in documenting what already exists here.

[axic]

I've seen on twitter that apparently there are at least 3 different semantics contracts follow and still call it "permits". @MrChico you proposed to discuss all in the EIP/ERC.

I think an EIP should be unambiguous and promote a single way of doing things. Is it possible to do that while perhaps mentioning "semi-compatible" contracts? If not, would it make sense having 3 different EIPs?

[MrChico]

@axic I'm planning on mentioning the Stake-flavored implementation under "backwards compatibility", making that, the dai and chai implementations all belong to this " semi-compatible" class, but keep the specification as is for specificity

[axic]

Nice, sounds good!

[Nipol]

@MrChico Good! I think we've written quite a meaningful conversation in publicly.

It will be the data we or the next people will refer to when working in the future!
😉

[ptrwtts]

The standard ERC-20 race condition for approvals applies to permit as well.

Why not take the opportunity to fix this? Otherwise, we might end up with proliferations of safePermit too. Is the assumption that the allowances will be spent immediately, so it's not actually a problem?

[MrChico]

The standard ERC-20 race condition for approvals applies to permit as well.

Why not take the opportunity to fix this? Otherwise, we might end up with proliferations of safePermit too. Is the assumption that the allowances will be spent immediately, so it's not actually a problem?

To be honest I don't find the approval race condition to be much of an issue in practice – it's only ever a problem when allowing addresses that can "spontaneously" spend your allowance. In most use cases, you give your allowance to a smart contract in such a way that only you can later initialize the transferFrom from your own address.

I'm all for people implementing safePermit if they feel that this is a concern, but in order to limit the scope of what I'm trying to do here I think such alternatives should be in a different ERC