Update and extend tezos-caip2/10/122 + Tezos namespace

[jdsika]

@bumblefudge I can finally make some time to finalize this work which has been started in #40 .

I think you can review the following documents and decide if this qualifies for a status "final":

• readme
• tezos-caip-2
• tezos-caip-10

I am not sure if the required specifications need to list the respective namespace derivative or the original specification (or both)?

requires: ["CAIP-2", "CAIP-10"]

I have addressed this comment here:

Could we update CAIP-2 (and the chainIDs in CAIP-10 while we're here) with a Limanet and a Ghostnet example? If you could add, as I did in the CAIP-2 the genesis block hash, it helps people test their own computation of the chainID string for private chains or future testnets...

I will continue with your comments regarding the tezos-caip122

[jdsika]

Question:
If the chain ID is determined by the genesis block hash we have multiple chains with the same chain ID if a hard fork occurred where both chains share the same genesis block hash. How to handle this correctly?

[jdsika]

Question: If the chain ID is determined by the genesis block hash we have multiple chains with the same chain ID if a hard fork occurred where both chains share the same genesis block hash. How to handle this correctly?

The answer to this could be that the namespace prefix tells what the main chain is and we need to define a criteria in the tezos namespace document on how to determine "social consensus" like e.g. "the longest chain in Bitcoin"

[bumblefudge]

Question: If the chain ID is determined by the genesis block hash we have multiple chains with the same chain ID if a hard fork occurred where both chains share the same genesis block hash. How to handle this correctly?

this is truly a difficult problem, engineered with different combinations of technical and/or social mechanisms in each namespace! feel free to describe the tezos solution (non-normatively, and with links to the most-normative/most-canonical doc you can find in the tezosphere) in caip10.md and tag me for review when you're happy with the new draft 💪

[jdsika]

Can you point me to a document of a chain that has solved in the most elegant way? I actually think it is not solved in tezos (doing research ATM)

Also is it allowed to define an alias for the chain ID as I did it?

Update: I have described the Tezos solution in a paragraph. In addition I have created a ticket regarding a registry for aliases:
https://gitlab.com/tezos/tezos/-/issues/7023 because of the response here: ChainAgnostic/CAIPs#267

[jdsika]

@bumblefudge can you tell me what the rational was to not include the public key in the CAIP-122 data model but only the account id information?

[jdsika]

@royscheeren could you add a complete sample plain text message and a base64url-encoded byte representation as example in caip-122, please?

[jdsika]

@bumblefudge can you tell me what the rational was to not include the public key in the CAIP-122 data model but only the account id information?

Is the reason that looking at Ethereum the public key can be extracted from secp256k1 and the data model was taken from the EIP?

[bumblefudge]

@bumblefudge can you tell me what the rational was to not include the public key in the CAIP-122 data model but only the account id information?

Is the reason that looking at Ethereum the public key can be extracted from secp256k1 and the data model was taken from the EIP?

i'm not sure I understand the question entirely. In EVM, ECRecover is how you check a signature against an address (not knowing the pubkey per se, but being able to derive two of them from the address and check both against the signature). In other systems, like BTC and derivatives, different recovery mechanisms allow you to derive a public key from an address and a signature produced by its privkey. in systems like Solana or Polkadot where the address is (or is a simple transformation of) the public key, the derivation is simpler and does not require a signature. the logic of CAIP-122 is that these mechanics should be specified in the namespace's CAIP-10 profile, and left out-of-scope, since an account, rather than a public key, is what is being authenticated. does that help?

[jdsika]

@bumblefudge can you tell me what the rational was to not include the public key in the CAIP-122 data model but only the account id information?

Is the reason that looking at Ethereum the public key can be extracted from secp256k1 and the data model was taken from the EIP?

i'm not sure I understand the question entirely. In EVM, ECRecover is how you check a signature against an address (not knowing the pubkey per se, but being able to derive two of them from the address and check both against the signature). In other systems, like BTC and derivatives, different recovery mechanisms allow you to derive a public key from an address and a signature produced by its privkey. in systems like Solana or Polkadot where the address is (or is a simple transformation of) the public key, the derivation is simpler and does not require a signature. the logic of CAIP-122 is that these mechanics should be specified in the namespace's CAIP-10 profile, and left out-of-scope, since an account, rather than a public key, is what is being authenticated. does that help?

Yes, it helped and that is what I meant to ask. I do not see the requirement to derive a public key in CAIP-10?

Rationale
The goals of the general account ID format is:

Uniqueness between chains regardless if they are mainnet or testnet
Readibility using the prefix of a chainId to quickly identify before parsing the address
Restricted to constrained set of characters and length for parsing

I think I will not put the public key in the data model of SIWX and make a section that explains on how to get in Tezos and that is the responsibility of the connection layer between app and wallet.

[jdsika]

@bumblefudge I clarified the public key exchange. Feel free to start your review. Who should be the second necessary reviewer?

[bumblefudge]

Getting there! Just wordsmithing at this point, the content seems good
StakeNow#1

[jdsika]

Included @bumblefudge editorial review and discussion results

[jdsika]

Ping @bumblefudge

[bumblefudge]

Sorry! missed the notif that you'd merged the last PR on your side. 🤝

[bumblefudge]

feel free to tag me in any implementation threads out in the world, or if i can help on the tezos gitlab, i just updated my gitlab email so i should be taggable there as well (also @ bumblefudge)