CAIP-10 and CAIP-19: mandate case-normalization

[u59149403]

Let's talk about eip155/caip10 ( https://namespaces.chainagnostic.org/eip155/caip10 ). Currently the text says that generators SHOULD generate EIP-55-normalized addresses and SHOULD consume both EIP-55 normalized and all-lowercase addresses.

I don't like this wording and propose that eip155/caip10 addresses simply always MUST be EIP-55-normalized (i. e. generators MUST generate EIP-55-normalized addresses only and consumers MUST consume EIP-55-normalized addresses only).

Here is my reasons.

• My proposal allows one to check two EIP-155/CAIP-10 addresses for equality using simple byte comparison. Moreover, if all namespaces accept some normalization scheme, then one will be able to check any two CAIP-10 addresses for equality by byte comparison. (Note that CAIP-10 says in "Rationale" that "uniqueness between chains" is one of the goals.) But in current CAIP-10 version we have to use namespace-specific comparison. I. e. implementations forced to have complicated comparison function, which includes special cases for every namespace. This is very difficult. Moreover, implementations have to be updated every time CAIP introduces new namespace
• As well as I understand, one of the goals of CAIP-10 is to be usable in smart contracts, i. e. on-chain. Obviously, complicated namespace-specific comparison procedure will be too difficult to implement on-chain. Moreover, it will be very gas-intensive, compared to simple byte-string equality. Moreover, the procedure should be updated every time new namespace is added to CAIP-10, which is impossible for immutable contracts!
• Current wording makes checksum optional, which simply goes against checksum purpose. Whole raison d'etre of checksum is to be checked every time! Bank card numbers use last digit as a checksum, and it is always checked!
• We already have precedent: eip 3770 says that we MUST use EIP-55. And Gnosis Safe implements EIP 3770
• eip155/caip10 uses Postel's law as motivation for accepting all-lowercase address. eip155/caip10 links to IETF RFC 760 from year 1980. But later IETF RFC 3117 ( https://datatracker.ietf.org/doc/html/rfc3117 ) from year 2001 criticizes Postel's law in subsection "4.5 Robustness". Postel's law was important for early internet, but today security concerns outweigh Postel's law's flexibility

For all these reasons I propose to mandate EIP-55 encoding in eip155/caip10 and also to choose some normalization scheme for all namespaces, i. e. to make all CAIP-10 addresses case-normal. Also the same applies to CAIP-19.

Why this is important for me? I plan to create my personal accounting system for my cryptocurrency operations. I plan to use CAIP-10 and CAIP-19 to refer to addresses and assets. So high quality CAIP specs are important for me.

If you want, I can write pull request for EIP-155 namespace. (Unfortunately, I'm not expert for other namespaces, so I cannot write PR for them.)

[u59149403]

Lack of normalization was one of the reasons to create CAIP-350 PR #350 and ERC 7930 PR ethereum/ERCs#1002 . So, lack of normalization leads to proliferation of standards

[0xteddybear]

Lack of normalization was one of the reasons to create CAIP-350 PR #350 and ERC 7930 PR ethereum/ERCs#1002 . So, lack of normalization leads to proliferation of standards

For the record that was one of the concerns, the other was the lack of a compact binary representation

[bumblefudge]

The history of Postel's Law is funny-- and the irony that even Postel himself later backpedaled on whether it was a Law or just a rule of thumb is... literally an instance of Postel's Law/Rule-of-thumb 😄 . It's a logical Mandelbrot-fractal.

So, we've reopened this can of worms periodically, and I think it fundamentally comes down to whether EVERY POSSIBLE implementation of caip-10 for ethereum addresses (or for that matter, if EVERY POSSIBLE implementation of ethereum addresses in ethereum-only contexts) benefits from checksum, even resource-constrained use-cases where verifying checksum is a waste of precious compute, even use-cases with weird trust assumptions, etc etc. I agree that 99% of implementations SHOULD ONLY accept checksum case, verify that checksum every time they receive an address from over a trust boundary, and normalize to checksum anywhere they deserialize. The question is whether the ethereum profile of CAIP-10 needs to mandate this, or just recommend it. It's an implementation-level concern, so I've always been more comfortable with a recommendation or non-normative guidance. I don't have the confidence to declare that NO future implementation will EVER have a valid reason not to canonicalize; that feels like a decision better made in the Ethereum community and enforced by Ethereum tooling...

[bumblefudge]

P.S.

I plan to create my personal accounting system for my cryptocurrency operations.

neat! Lefteris from rotki spoke at a CASA unconference, and might be a good guy to reach out to about this-- he might prefer you fork rotki as your starting point, in case you ever want to upstream any novel helper function or features you end up adding 😅

[bumblefudge]

Also note: a slight rewording/clarification of CAIP-10's Canonicalization section was proposed last year, i'm still waiting on the original author's thumbs-up before merging