Before replying any message, I’d like to clarify an important point. My personal objection to the current form of 7702 due to bad security trade offs for EOA users, seem to have raised concerns that ERC-4337 will not support it. I want to reassure everyone - that is not the case.
My current objections are not related to AA. As long as 7702 is compatible with the AA roadmap and doesn’t degrade 4337, we intend to support it. The current version is not great for EOA users but will work fine with 4337, so the protocol will support it.
Not trying to publicly vilify you, just to show that what you wrote is inconsistent with something you wrote in the past. Something you have done yourself in past debates we had - taking an older message out of its original context and trying to show that it’s inconsistent with what’s being said in a different context. It’s strange that you take personal offense, given that trying to prove inconsistency is a method you often apply yourself.
Anyway, my intent is not to vilify anyone so let’s move on.
Neither are other ways we tried. Any argument not consistent with 3074 gets brushed off.
As I wrote many messages ago in this thread, I already made my case and debated the trade offs of every point in 7702, so I meant to stop debating and let the community decide based on that. I had to jump back in because you didn’t wait for the community to reach consensus and just edited the EIP to match your preference. Had you not done that, you wouldn’t have heard another word from me about revocation, etc.
We both made our case and it seems that further debate won’t get us anywhere. We should both take a step back, let the community debate it, and only jump in when something is misunderstood and requires clarification. But you editing the EIP before consensus is reached, is incompatible with that.
I noted the same thing myself on a 3074 breakout call, long before it was included. Using the nonce directly is too restrictive and kills many good use cases. Therefore I proposed maxNonce+bumpNonce during that call. It never made it to the proposal so no one had a chance to evaluate it as an alternative to nonce or to no revocation. Those external people you’re talking about didn’t object to revocation in general, they objected to the restrictive revocation method you chose to include in 3074 despite having a less restrictive option.
That’s why I suspected from the start that there will be an attempt to remove it later. If the intention was to really have revocation in the final version, you would have chosen one that doesn’t restrict use cases. The “chip away” message just confirmed what I assumed earlier.
In the current thread you stated that your preference for 7702 is no revocation > max nonce > current nonce. Since max nonce was also proposed for 3074, choosing current nonce seems strange if you intended for it to get included that way.
In the scenario I described, the wallet is the attacker preparing a rugpull. Therefore it will prompt the user to sign whatever contract it wants. This hypothetical wallet lets you connect your Ledger, sponsors your transactions for the first month to incentivize you to use it, and keeps the authorization you signed - for a perfectly legit contract that just happens to be deployed via a CREATE3 factory. After a month it stops sponsoring gas and you move to a different wallet, not realizing that your account is no longer safe. A year letter, your assets on other chains start getting drained on other chains. The first wallet effectively stole the private key from your Ledger, despite having never seen the actual key.
An address is fine as an optimization, if the signature is over keccak(address+code). The code doesn’t need to be in the transaction if it can be read on-chain. The problem in the new version is that code was replaced with address rather than a signature over both.
I believe I have done that. And the rationale is still incorrect IMHO. To take just one example, I have yet to see a flow in which clients will need to perform a database lookup on the account’s code but not to also load the code for execution. Transaction propagation doesn’t require that, and block validation requires the entire code anyway. Another thing is that the rationale makes a false assumption that the EIP will only be used in one way - each EOA only ever signs one contract. That is inconsistent with how people have been building invokers so we have no reason to believe this time will be different. If the only safe way to use the EIP is “as intended” then the EIP should not make other, unsafe ways possible.
The rationale you added is just… rationalizing why the pre-inclusion 3074 is the right model. Everything is written in support of that, and any contradicting evidence is ignored. This may work on those who aren’t that deep in the weeds and may not understand the nuances above. But you are smart and very familiar with the topic so I assume you do understand. You just choose to ignore it.
