The scenario where neither changes is pretty much unresolvable (no replay protection), but I would contend that social friction will enforce either 1. or 2. happening eventually (after a fork occurs).
It is exactly for the same reason I believe we should only cater for case 2) since case 1) can be solved similarly to what you describe. This is why the opcode I propose is sufficient without requiring any “user-handling”
Lastly, this increases complexity on the client implementation because each contentious fork would have to maintain yet another value in the lookup table (so it knows to return True or False). If we upgrade the value on every fork we do, then that’s even more on the client side!
This is true. I never argued for the contrary but the idea has its purpose and should not be a problem.
In any case as you mentioned you would need a similar strategy for your version of the opcode since in order to accept message signed with old chainIds, you would need a global caching smart contract for case like counterfactual state channel situation where the contract do not exist yet for example.
Conversely, in my proposal we do not need user-side handling to obtain the value of chainId because the opcode provides the current value.
I do not consider that user-handling. This is just passing an extra parameter for message signature verification. But if that is what you are concern about, I ll let you call that user-handling.
But again with your opcode, this chainId will also need to be supplied anyway if you want to support old message, which was the whole point of my proposal.
What would be best is to retain this opcode (that returns current chainId) and propose a new suggestion that takes a value of chainId and returns the timestamp of when the fork occurred where that value was introduces. This resolves all discussions of user-side handling of time, and makes it much easier for developers to handle these upgrades, especially in the proposal where we move to every fork changing this value.
You seem to overcomplicate things here. Assuming all fork have an updated chainId (which yourself describe as likely for the case when none of the fork change Ids) none of this is necessary
To resume how I see the situation is that since forks can always update chainInds, we should consider the case where both fork update their latest chainId to different values (an outcome that is beneficial for both side of the fork)
In that scenario, the opcode I propose is safe and sufficient.
Now if you think we need to tackle situation where a community refuse to update its chainId at the expense of its users, then I think such community can decide to come up with a more complicated scheme to solve that. I am personally think this is unnecessary.
Anybody else interested to comment ?