EIP-1191: Some minor changes

[alcuadrado]

This PR makes some minor updates to EIP-1191:

1. It changes the example implementation to encode with the new algorithm whenever there's a chain id. Rationale: if this EIP is going to be implemented in other chains, the example implementation should also work with those.
2. It updates the mainnet test cases to reflect the previous change.
3. Added Web3.js to the implementation table.

[eip-automerger]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

• EIP 1191 requires approval from one of (@juli)

[axic]

Would be nice to also solve #1191 (comment)

[axic]

@juli please review

[axic]

@juli ping

[juli]

Hi, sorry for not answering before. Thanks for the interest in this EIP @alcuadrado

• The link to web3.js and other minor improvements are now in EIP-1191: Change status to Last Call #2234
• The eth_mainnet checksums of this PR are wrong because they are calculated as if Ethereum Mainnet addopted EIP-1191 (chain id 1 part of the hash input) but EIP-1191 is backward compatible until Ethereum Mainnet decides adopting it.
• I don't see why letting the caller decide to pass chain id or not is better than including the list of chain ids that adopt EIP-119 inside the checksum function.

[alcuadrado]

Hey @juli, thanks for your answer.

• I don't see why letting the caller decide to pass chain id or not is better than including the list of chain ids that adopt EIP-119 inside the checksum function.

The rationale for this is that there's no entity that could decide if this EIP is adopted or not by Ethereum, and as it's not enforced by the consensus rules, it can't be decided by the community either. Then, this EIP can only recommend a new checksum that each app developer is responsible for deciding if it should be used.

• The eth_mainnet checksums of this PR are wrong because they are calculated as if Ethereum Mainnet addopted EIP-1191 (chain id 1 part of the hash input) but EIP-1191 is backward compatible until Ethereum Mainnet decides adopting it.

Same here. As there's no such a thing as "adopting it", IMO the test cases should use the new checksum algorithm.

[juli]

Each network can decide in the same way they decide to use hexadecimal addresses or something else. In practice it was implemented by wallets following the backward compatible logic, with RSK as first adopter of this EIP and assuming Ethereum Mainnet won't change how checksum is calculated.

[axic]

I would agree with @alcuadrado that if this EIP is Final then how could anyone adopt it as that would mean changing the Final EIP to update the specification?

It makes a lot more sense to specify how to calculate the checksum and leave the adoption outside the scope of this EIP.

[juli]

Discussion moved here.

[juli]

EIP has been already implemented as originally suggested.

[axic]

EIP has been already implemented as originally suggested.

Can you explain what this means? I'm unsure.

Btw if the current wording of the EIP is adopted, that means no other chain, only RSK, can make use of it. For one simple reason: a Final EIP can not be changed and since this EIP codifies which chains enabled it, that list cannot be expanded.

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.