-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAIP-10 Proposed Changes #51
Comments
I support these changes and we would be happy to adopt the updated CAIP-10 address format with Gnosis Safe. |
I am also in favor of B (although I think we should keep eip155 and not evm as evm is to broad and eip155 is where the chainIDs are coming from) - but not really sure we should change CAIP-10 - this might be a bad precedence. I think it is better to create a new one and just let CAIP-10 die. |
My motivation for changing CAIP-10 is mainly because we didn't finalize its status yet besides I wouldn't want to create another CAIP standard that doesn't offer much changes While CAIP-50 is a more compact and efficient format than CAIP-10 by encoding all accounts in the same base and even introduces a checksum CAIP-10 (both versions) attempt to preserve the same readability as the original account addresses by simply prefixing or suffixing the CAIP-2 chainId |
I am in favor of B as well. It follows the same logic of CAIP-19 where we always start by the chain-id. |
In what way is Can you point out any edge cases where |
It is mainly about being future compatible - the EVM might live longer than chainID's. Also it is a separation of concerns. We take the number from the chainID introduced with EIP155 - not from the EVM |
yea - it's a short-hand now - but can bite in the future. Be future compatible .. |
This direction makes our work with did-pkh a lot easier. +1 to simpler and more recognizable representations. |
One suggestion: instead of using I'm going to tentatively move forward w this Eth address: I'm following @pedrouid's lead here btw & only using the first half the bip122 chain id (aka genesis/forked block hash). Not sure if that's a widely adopted standard but the full bip122 id is too annoyingly long. |
this was one of the reasons that we first started with namespaces labelled after existing standards like the issue with |
How do you feel about |
here are some design goals for consideration by the group:
|
Which UTXO chains couldn't be identified by the hash of the genesis/fork block? If I understand correctly, Z-cash and Monero both have genesis blocks that could be hashed & used as IDs a la bip122. I'm not sure which other UTXO chains are out there tho tbh.. Either way, I agree w @wyc that
@ukstv CAIP-19 defines globally unique asset specifications & we can use some of these patterns to make this distinction. eg DAI could be |
@wyc when it comes to compactness and reducing bandwidth I think that CAIP-50 (#50) should be used instead which could be interpreted as a special encoding of CAIP-10 Another reason to not use When you use any Ethereum ( That is why I would oppose to using |
Using a common prefix such as this, and conforming to URI syntax as options B and C appear to do, opens the possibility of using CAIP-10 identifier as URIs. https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml |
CASA Meeting #1 notes:
CASA Meeting #1 results:
|
Exactly. |
Should've been closed by #59 |
CAIP-10 has received a lot of feedback within the last year including some criticisms over its structure. Many Twitter and Discord threads have been written about what would constitute an ideal multi-chain account identifier from which it has also generated new CAIP proposals (#50).
A lot of feedback has also been generated recently in an Ethereum Magicians thread: https://ethereum-magicians.org/t/chain-specific-addresses/6449
Additionally some polls were also created on Twitter:
Poll 1 - https://twitter.com/SchorLukas/status/1404831686714613769
Poll 2 - https://twitter.com/pedrouid/status/1404869512512606218
From my perspective there is essentially a division between 3 main identifiers:
From both polls and also from the Ethereum Magicians thread, the majority supports the identifier with format B.
This would mean that it would require the following changes:
I propose that we make these changes to respective CAIP standards which are in DRAFT status with two separate PRs for each change and follow up with discussions for each.
The text was updated successfully, but these errors were encountered: