ChainID 101 conflict

[ethereum-lists]

ChainID 101 conflict

[pedrouid]

It's no big deal as these two chain look the same, so it could be either a typo or a duplicate entry.

There can only be one chain per chainId as per EIP-155 spec so we need to be the judges of conflicting scenarios like this. This is not the official list of EVM as there will never an official list but it's a trusted signal for listing EVM chains.

I checked and these two chains were part of the same commit: 9acc67d

Hi @hackmod, could you review this chainId conflict and tell us where we could verify if this is a typo, duplicate or something else?

[pedrouid]

Thanks @hackmod! This makes it clearer that they are not the same chain and there is indeed a chainId conflict

  {
    "name": "Webchain",
    "short_name": "web",
    "chain": "WEB",
    "network": "mainnet",
    "chain_id": 101,
    "network_id": 37129,
    "rpc": ["https://node1.webchain.network"]
  },
  {
    "name": "EtherInc",
    "short_name": "eti",
    "chain": "ETI",
    "network": "mainnet",
    "chain_id": 101,
    "network_id": 1,
    "rpc": ["https://api.einc.io/jsonrpc/mainnet"]
  }

Now we need to decide how we handle these and apply process for the future. Given that there is a clear lack of resources on these chainIds.

I propose that we list both conflicting chains and highlight active conflicts on the chainId.network website. This way we have a good signal of these events happening in the future and we can kickstart the process to solve them.

In my opinion, the first chain to use the chainId should not have to change the chainId. Therefore when these conflicts appear we should contact and/or open a Github issue to request the second chain to change their chainId.

In this specific conflict, WebChain should change their chainId since EtherInc had the chainId first as reported by @suryanshkumr on issue mintme-com/webchaind#1

[pedrouid]

Cool, just updated the list on commit 09c24317a22c56f92a5460793b704f362aadd7b9

[ligi]

I signal to remove webchain. IMHO we should really discourage duplicate chainIDs as it leads to possible replay attacks and ugly code.
Etherinc produced the first block before webchain - this is the root of my signaling. And IMHO we should also use this as a guideline for the future.

what do you think @pedrouid @bmann

would be great to have a decision on this soon as #40 depends on it

[ligi]

I do not really want to be the judge of this. Can't there be both?

[bmann]

It’s a really interesting case. I think informing both “owners” and helping them pick an un-used chain IDs is something we can help with.

They don’t have to listen to us of course, but I think it’s the exact sort of thing that’s helpful for us to do.

eg “before picking a ChainID, review ChainID.network and select an unused ChainID”

[bmann]

Great. This is great info for the About page re: EIP-155 and to explain the goal here.

[hackmod]

unfortunately, it is not a typo.
Please see MyEtherWallet/etherwallet#2145

cc: @suryanshkumr @lukaszmatczak @mk

[lukaszmatczak]

I agree that we need to resolve it somehow. But I think that root of this problem is inside EIP-155 specification. I've created issue about it: ethereum/EIPs#1747

We need to wait and see how it will be fixed in specification and then resolve this conflict properly.

BTW. And of course there is a typo in list. EtherInc has "web" as "Short Name" and "Chain".

[ligi]

BTW. And of course there is a typo in list. EtherInc has "web" as "Short Name" and "Chain".

what should these be instead?

[hackmod]

BTW. And of course there is a typo in list. EtherInc has "web" as "Short Name" and "Chain".

what should these be instead?

oops my mistake! that's ETI.

[pedrouid]

Hey @lukaszmatczak, do you have an update on the chain_id fork for Webchain?

[lukaszmatczak]

@pedrouid Yes. We've just released new version of our daemon. Hardfork is planned on April 8th (height 2,022,222).