Although I think the case where a user needs to manually relay a 3074 msg which isn’t getting picked up by a relayer is small, this seems like a reasonable modification to me.
It still doesn’t abdicate the invoker from performing replay protection. Now, if a user has an auth message relayed (nonce N), they may use that message again during self-relaying. This is reverse of the current situation.
One of the use case that was put forward is EOA multicall.
Wallets such as Metamask may expose a multicall endpoint that relies on a forwarder to execute a batch of operations signed by the wallet. If you are trying to replicate the current EOA UX, you don’t need to add in the extra cost of having to refund a relayer that pays the gas.
I’m expecting this usage, that requires minimal infrastructure beside basic wallet support, to be the first usage of 3074
There seems to be some incongruence in the EIP, the section that defines what message AUTH validates seems to include replay protecting aspects such as a nonce and chain ID (^1):
The arguments (
yParity,r,s) are interpreted as an ECDSA signature on the secp256k1 curve over the messagekeccak256(MAGIC || chainId || nonce || invokerAddress || commit), where: […]
While the security consideration section seems to imply that handling of replay protection is left up to the contracts and the only signed over is the magic, invoker address and commit?
I wonder, if ERC-2098 Compact Signature proposed by @ricmoo has been considered in EIP-3074 which allows a signature to be represented by 64bytes instead of 65. It seems it has not been mentioned much in this thread. Bear with me if this has been answered already.
As @Amxx mentions above, the user’s nonce doesn’t increment when their tx is relayed by someone else. So absent replay protection on the invoker side, Bob could relay Alice’s message an unlimited amount of times.
Intense!
That is a feature! Nothing wrong with this (if the invoker is properly designed and the user understands what he/she signs)
Would be possible to have a variable for timestamp of creation and a timestamp for expiry on these signatures ?
I agree, but then why put the nonce in the signature at all? That protection is also unnecessary if users understand what they sign and only use well-designed invokers. Plus it creates the weird inconsistency you describe above!
In practice not being able to invalidate anything ever seems riskier, but in general you have to assume I think that one bad sig drains you in either case.
I think it’s an amazing EIP so not trying to be too critical, just wrapping my head around it.
It is possible but only if the invoker contract demands it. At the protocol level the signatures never expire.
A couple contract already have this implemented, but if we getting a fork this big might as well add it on a protocol level
This proposal languished for quite some time because there was no in-protocol revocation. Adding nonce was @matt’s compromise to get something on mainnet.
We hadn’t thought about it, no. That is some clever packing!
An invoker contract could implement that to save calldata/storage, or we could extend the supported signature formats to allow it in a future EIP.
Unless there’s a significant gas overhead to doing the transformation in the invoker, I think I’d rather stay with the current signature encoding for now.
Our philosophy has been to keep the in-protocol parts of 3074 as minimal as possible: if it can be implemented in the EVM, it should be implemented in the EVM. This gives as much power as possible to invoker implementers.
Makes sense as to avoid most contacts becoming obsolete, but what happens if an invoker gets exploited
Signature validity and signer recovery is handled analogously to transaction signatures
Does this include reverting if the signer account has bytecode?
My core question was more whether the nonce should be part of the top-level auth message but that’s a good point that either way it doesn’t provide native replay protection, merely the possibility of revoking an authorization but submitting an on-chain transaction.
To add to this I don’t think it’s a good idea to include the chain ID in the top-level message, this should be a design choice made by the contract to allow for chain agnostic / multi-chain use cases.
I’d like to put in a case for leaving chainId replay protection up to the invoker with a tangible example where cross chain replay by design is quite useful
A powerful underexplored pattern with 3074 is to use an invoker as the primary source of authentication logic. This can be done by crafting a one-time AUTH message with no replay protection and generating a synthetic signature so there is no underlying private key. Now that 3074 supports native transfer this effectively allows for singleton SCW implementations and near-full SCW functionality without deployment required
Enforcing chainId severely limits this pattern as a given account generated this way must be chain-specific, causing horrible multichain wallet UX.
@SamWilsn is the EIP already “finalized” to a point that you (the coauthors and the EIP reviewers) for sure won’t consider leaving chainId and nonce out of the signed message?
Personally I think it would be a huge missed opportunity to not give Invokers complete flexibility in implementing their own replay protection and revocation mechanisms. Revocation in particular should be VERY easy to get right in terms of audit – if you want to be sure that your Invoker uses authorizations that can be revoked via nonce, just check if the nonce is part of the commit.
For those of us who didn’t follow 3074’s entire journey, can you share the main objections to leaving replay protection / revocation for Invokers to handle?
You don’t need to convince us authors; we had originally spec’d this out without in-protocol chainId or nonce. We added them as concessions to get something into a fork.
You need to convince the core developers on AllCoreDevs that we don’t need in-protocol enforcement of these values. Many of them have commented in this thread with their reasoning.
I guess there’s no shortcut to reading this entire thread 
The thing that kills me about including nonce is that now sending any EOA transaction invalids all outstanding authorizations. Many people use many different wallets with the same EOA, and now if some of these wallets are 3074 and some of them are not, the non-3074 wallets will screw up the 3074 ones. So you have to be all-in on 3074 wallets.
Anyways, will read the thread and try to understand the objections.