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.
1 Like
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.
1 Like
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?
1 Like
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.
1 Like
@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?
1 Like
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.
1 Like
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.
3 Likes
Actually I noticed that this section says that the only signed fields are invoker and commit, contrary to the actual spec. Probably forgot to update this part?
To be clear, I am also in favor of only signing invoker and commit.
Thanks! How’s this: Update eip-3074.md: explain `nonce` and `chainId` in rationale by SamWilsn · Pull Request #8428 · ethereum/EIPs · GitHub
Did I get it right that now it will be possible:
With auth opcodes, imagine you just send eth to some address, but that address is a contract and your wallet won’t even tell you, you think it’s a regular token transfer, but not, the dest will ask your tx for this auth call. You won’t notice anything, but account will be compromised
No, you have to sign a separate message (with the 3074 type byte) and relay it on-chain. Additionally, signing a 3074 auth doesn’t mean your account is compromised. If the invoker is well implemented, it’s just as safe as a transaction from a smart contract wallet.
Hey guys! excited to see this EIP being included in the upcoming fork.
I do have one questions around impact of this EIP that i saw someone discussing and wanna confirm here: Will this EIP be able to enable “permanent” delegation to a invoker contract? I saw someone mentioned an uescase where users can use their EOA to “delegate once” to a multisig and use that to send daily txs on behalf of the EOA.
My understanding is that AUTHCALL can only happen after AUTH within the single call frame, so every time a contract needs to make AUTHCALL, it needs a (new) signature by the original EOA owner. This would mean the usecase above is impossible. Am i correct or is there other ways to bypass this?