EIP-1344: Add chain id opcode

[fubuloubu]

@wighawag

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”

So the issue here, and this is why it needs to handle both scenarios, is there is currently no plan for it to work like this, so we can’t rely on “the community” adopting your suggestion without another separate proposal.

@wighawag

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.

The difference is that my proposal would be more flexible (you don’t have to do it unless you want to) whereas yours you would have to design in some mechanism. Counterfactual instantiation is an interesting counterpoint, but I could imagine some scheme that would only care about the current value provided by some final message signed at closing time, in which case my proposal would work (without modifications!)

Another point is that you would have to pass in the chainId in your proposal separately to generate the domain separator. I think this may be too far down in the realm of implementation details to discuss further, it’s simply an engineering tradeoff. I think we’re largely at an impasse with two equally viable methods to implement this functionality.

---

Here is what I suggest:

1. We should put this EIP into Last Call as currently written as it’s well-specified and can be used as a technical standard as is.
2. You should create a separate EIP from your proposal as I believe it has value, and I also believe both could play well together!
3. We probably need a third proposal to specify the process of setting chainId that is completely separate from this discussion. It is likely to be political in nature (as the length of this conversation surely attests to!), so siloing the political discussion away from the conversation for this opcode (and your proposal) would help bring this to a close. There is a significant opportunity to improve resilience of any signing scheme that uses chainId, but that is out of scope for this proposal (and yours as well)

---

I hope everyone finds this to be reasonable, as I believe further discussions along this point may prevent this conversation from ever being brought to a close, which means nothing gets done and that’s worse for everyone. The conversation about whether this proposal (or another) is included in Istanbul is also a separate conversation I believe needs to take place on an alternative channel.