A case for a simpler alternative to EIP 3074

[matt]

@yoavw

The point is not that I found an edgecase not yet included in the best practices, but that someone else will find another one in a year or two, and EIP-3074 makes users vulnerable to any future discoveries.

This is not a security issue of EIP-3074, but rather a philosophical disagreement. I trust that we can develop safe contracts. We have many contracts that are considered safe such as the Uniswap contracts, Gnosis safe, Argent wallets, etc. If you don’t trust those, don’t use them. If you don’t trust EIP-3074, don’t use it.

@yoavw

What about whitelisted ones that will have well-hidden intentional bugs, to be discovered at some point in the future?

What happens if Gnosis Safe hides a bug deep down in their smart contract only to call in at some far future date? The point of smart contracts is for them to be trustless and publicly auditable. We can write safe contracts. What criteria wallets require before using an invoker is an important, but different matter than the EIP itself. I have described a framework in which this can be done safely.

@yoavw

Switching from an EOA to a contract wallet in-place is a nice hack

This is the long-term vision of Ethereum. I am proposing that EIP-3074 can help this effort while improving usability drastically.

@yoavw

If you own an ENS name and want someone else to be able to change certain ENS attributes, transfer the ENS name to a contract that accepts any operation from your EOA, and specific attribute changes from another EOA.

It’s not about the specifics, it’s about the class of things EIP-3074 allows. Transaction malleability allows EOA to make delegations off-chain. This is extremely powerful. Your example requires another contract be deployed. My proposal costs the user nothing.

@yoavw

@matt

• specialized invokers - Some actions are very common, like approve-call. It would be more gas efficient allow a user to sign over just the approve-call invoker with their call and have that signature be used implicitly to authorize the approve.

Why is that not possible with my proposal or a similar one, where the user signs a list of calls? The wallet will know that the invoker is performing both the approve and the call, so it will put them in a list, sign that list, and send the signature to the invoker. No need for a blank check because everything is known in advance.

I see, yes in that case this one is okay.