CIP4 - Wallet checksum

Hello friends,

I have posted a CIP to talk about wallet checksums – the icon + text you see constantly in your Yoroi extension wallet

image

The CIP describes two things:

  1. How we generate icons for Byron + ITN
  2. An idea for a new scheme going forward

I would love any feedback on (2) since it’s hard to change this after Shelley mainnet has shipped.

10 Likes

I think we should have different or different type of plates for a wallet apps. E.g. Wallet (I would say Bank is more accure) plate, account plate etc.

I meant by wallet (as there are lot of different meaning, terms and definitions):
A banking like application (mobile Desktop etc.) for different cryptocurrencies e.g.

  • coins (a cryptocurrency that has its own blockchain, like ADA, BTC or ETH.) and
  • tokens (a cryptocurrency that is built on top of an existing blockchain e.g. any ERC20 tokens)

that are based on one or more coin specific Blockhains, but are derived from one common seed. For, simplicity, I excluded the wallets that uses different seed (mnemonics) for different coins.
E.g. a wallet can have BTC, ETH, ADA and other coins and their tokens in the same time even they all three use different blockchains, but uses the common seed.

Also, what is the plate number and wallet relationship in these case or the cases where the wallets can have different coins recovered from different mnemonics?

I think maybe this is addressed by this part of the spec

To satisfy (1), the checksum SHOULD be seeded from the public key for the wallet. Notably, in the BIP44 case, it should come from the bip44 account derivation level’s public key.

Even if a wallet has multiple cryptocurrencies from one recovery phrase, the bip44 account derivation level is unique for Cardano because the cointype in the BIP44 derivation is different from the ones other cryptocurrencies use.

I should also note that for Shelley, we have totally different checksum images for stake pools
image

We did this because we thought it was better that different types of objects have totally different kinds of checksums to avoid user confusion. Similarly, this is the reason why addresses in Yoroi don’t have any checksum image (even though it’d be nice to have!). We would need to come up with a 3rd library that generates an image from a hash but we’ve never spent the time looking into that.

5 posts were merged into an existing topic: [meta] what collection of CIPs is required for sufficiently describe wallet software

I haven’t the vaguest idea what you guys are talking about but it sure sounds important.
I’m glad all you code talking peeps do what you do and do it so well in the ecosystem.
Good to see a Brissy boy doing his bit _ilap
Cheers,
D

1 Like

This technique could be useful when doing the % 10000 operation:

to ensure that every 0…9999 corresponds to a different value.

In the CIP, when it says 65025, does it mean 65536=2^16?

Would a versioning flag be useful so that in case you in the future wanted to use something else than FNV-1a you could flag for this?