I definitely consider any such discussion of how to manage
chainId
out of scope for this proposal. I think that the ability to ensure safety when a change occurs is an important point, and we have a few proposals above. It really doesn’t matter what the number is that is chosen, it either is or is not what the previous value was.
I did not meant to have this as part of the proposal per se (as we will never be able guarantee that a chain will not simply reuse existing chainIds for whatever reason). I was simply pointing out that by using this process we make sure that 2 forks will always have different latest chainId which remove re-playability between them. No need for oracles. Plus even if such process is not used, the part of the community that disagree with the changes can always fork with a new chainId themselves.
We agree that 1) is not an option
as for 2)
- Cons: requires a time oracle or user-side handling to ensure safety
I disagree with that statement. As mentioned we do not need an oracle as chain can always fork on a contentious fork. And as mentioned above, a process could make that automatic.
As for “user-side” handling, there is no extra work to be done by the smart contract when using option 2. It simply use that opcode passing the chainId used for signing the message as input and check the return value (true or false). This does not need any extra handling, contrary to option 3 where you rightly mention that it:
- Cons: requires user-side handling to ensure old chainId is accepted
This is basically emulating the opcode of option 2)
why not then simply use option 2) ?