[meta] what collection of CIPs is required for sufficiently describe wallet software

Developers CIPs
1

If anybody wants to develop wallet software for Cardano, ideally they would have a clearly define set of CIPs to look at that fully describes all the information they need to make a compatible wallet. This meta thread is to figure out what this set of CIPs should be and to help draft & standardize them

Currently we have

  • CIP3 - Master key derivation
3 Likes
2

Sorry, I was not clear. My bad.

I meant by that: in Yoroi the wallet (as a HD wallet from now on) is represented (for humans) as a plate number thatā€™s composed from an account key, of which the derivation path is m/44'/1815'/0' (Byron) or m/1852'/1815'/0' (ITN). So, therefore the relationship is: account plate 1ā€“>1 wallet. Even in the newest Yoroi, when we can add more wallets. So, the wallet is represented by that account plate (for humans) and account key is derived from one mnemonic. But, imagine if we will have a Wallet that can contains different account (some of which can be neutered) that derived from the same seed by the same or different methods/funcs, in that case that plate number represents only the account and not the wallet. Therefore, plate number should be interpret as account id only.

Also, the account derivation from a mnemonic can be represented as one derivation path for example: w/s/m/p/c/a where the:

  • ā€˜/ā€™ is some function where the left side(s) is the input and the right side is the output of that function.
  • w is the x-word mnemonic, whihc could be generated, by BIP39, SLIP39 or other standards that use some words for deriving the master seed. This applies only to recovery, and I did not include the initial entropy for seed generation.
  • s the generated master seed from that mnemonics, by some standard (BIP39, SLIP39 etc.) or just a simple 128-512bits long entropy (not relevant in this context).
  • m the master (root) key or extended root private key etc. derived from the seed by some standard BIP32 or by some non-standard ways like the Daedalus, Yoroi, Icarus, Ledger etc.
  • the rest ā€˜p/c/aā€™ is
    • the key derivation path for some BIP44 compatible wallet structure standard. (for simplicity I excluded the Deadealus old random index derivation path)
    • that uses some key derivation standard e.g. BIP32, BIP32-ED25519, SLIP10.

In Bitcoin, this path can be defined by two standards (I excluded the addressing i.e. key to address part):

  1. ā€˜w/sā€™: seed generation e.g. BIP39
  2. the rest is the BIP32 compatible BIP44 wallet standard
  • master key/node generation
  • key derivation
  • key identification (how the key is stored in the block) and
  • key serialisation (how the key can be imported/exported. It also contains some metadata for keeping the derivation path. In old Daedalus this is encoded in the address itself.

In Cardano we do not have these well defined wallet standards.
For example: Yoroi, while it uses BIP39, for the master seed, does not follow the original master key/node generation part of the BIP32-ED25519 standard. Thatā€™s understandable as it discards about half of the master seeds. Therefore it replaced that part of the standard, even all of the wallets that implements that BIP32-ED25519 use some self-modified master key generation, which IMO is not really a good idea.

Even, in Yoroi, despite they use BIP39 that can contain a passphrase for plausible deniability, Yoroi introduced an other passphrase in their master (extended) key/node generation function, which IMO should not be included, as itā€™s not that part of its responsibility, we should left it for the BIP39, SLIP39 or other standards (I know it introduces some hashing redundancy e.g. HMAC-SHA512 in BIP39 and SHA512 in BIP32 and BIP32-ED25519).

So, we have mixed standards (plate numbers including), with which we would need to live for long.

So, (HD) wallets should need to have at least these standards

  1. Seed Generation (e.g. BIP39, SLIP39 etc) including plausible deniability features
  2. Hierarchically Deterministic Key (Yes key and not wallet) Derivation Specification (e.g. BIP32 or BIP32-ED25519, not including plausible deniability features)
    • master key generation (BIP32 and BIP32-ED25519 cannot be used but we do not have any standard of this)
    • key derivation and therefore key tree specification, optionally (BIP44 or standards based on BIP44 are good candidates with BIP32-ED25519, but we do not have CIP for this either)
    • key serialisation (for export/import that contains some derivation metadata we do not have any, itā€™s a nice to have feature) and
    • key identifier (how the key is stored block, the current just stores the public key in raw format, so there are at least 3 reason why itā€™s not a really good idea, but that wonā€™t be discussed at all, IMO).
  3. Wallet specification (the above standards used and the following too.)
    • Wallet Layout a.k.a. scheme (should be based only on BIP44 standard e.g. an imaginary CIP1852 for the Shelley format)
    • Address serialisation specification and/or (CBOR? or what? why? and where?)
    • Address encoding/decoding (bech32).
    • Human representation of the wallet, accounts and/or other objects (plate number, wallet-, pool- an/or contract ids etc).

So, we need make some standard for these points E.g a modified or extended version of the BIP32-ED25519 that contains how the master (extended) key is generated as atm all the different wallets implementing their own, but that would be nice if Cardano should have some standards/recommendations that could be used for designing 3rd party wallets.

3 Likes
3

So, therefore the relationship is: account plate 1ā€“>1 wallet

The Yoroi API layer allows for multi-account and even arbitrary standards for derivation paths that we abstract to something we call a ā€œpublic deriverā€ ā€“ we just donā€™t have anything in the UI that exposes this. The reason the CIP isnā€™t called ā€œaccount plateā€ or anything referring ā€œaccountā€ is because itā€™s a generic scheme for any wallet generation strategy that contains a public key.

E.g a modified or extended version of the BIP32-ED25519 that contains how the master (extended) key is generated as atm all the different wallets implementing their own

Perhaps youā€™re looking for CIP3?

Address serialisation specification

For Haskell Shelley itā€™s defined here and for Jormungandr itā€™s defined here. Unfortunately we donā€™t have a standard that allocated bech32 prefixes though (but Haskell reuses the same prefixes as Jormungandr like addr1). For Byron-era addresses, Iā€™m not aware of a clearly written specification ā€“ just documentation of the code.

for export/import that contains some derivation metadata we do not have any, itā€™s a nice to have feature

You may be interested in my specification for wallet export & import. It also described the ā€œpublic deriverā€ concept I mentioned earlier in this post.

we need make some standard for these points

I agree, which is why Iā€™ve authored a lot of specifications and pushed hard to get the CIP process started.

3 Likes
4

No, I meant some standard serialisation for an address, like in BIP32, tha contains some metadata for easily importing/exporint only keys (with some metadata path etc).

Thx, just read it now, but read aderstiaā€™s some time ago.
So, tackle down the issues for Shelley mainnet.

  1. I prefer BIP39 or any other standards for seed generation, therefore we do not need an additional password protection.
  2. For master key gen I prefer Byron, the reasons is no any additional recovery password is introduced (i.e. no unnecessary redundancy).
  • Also, we could argue on that the created master extended key is BIP32-ED25519 compatible by nature (i.e. derived from seed by iteration) or by force (manually set). I prefer, the Byron solution, but thatā€™s jsut some cosmetic issue. Or combined or whatever, but some standard is required.
  1. For key derivation function BIP32-ED25519 is fine.
  2. For path derivation, we should have CIP e.g. CIP1852 or similar
  3. For key identity: nothing atm
  4. For key serialisation: The normal Shelley keys def for different keys (single, account etc) in the CIP
  5. Address encoding/decoding should be in a CIP
  6. Address serialisation: Some export/import format that contains some path info too, for key export/import.

For compatibility issues, we should define some wallet description in which we should define the building blocks (based on standards or some inherited spec/code etc) that are used for a concrete implementation of a wallet description.
And wallet implementation, like Yoroi, could have multiple different wallet descriptions (for only backward compatibility). For example, building blocks used for recovering a wallet.

  1. Wallet description name (we could have some versioning for them too)
  2. BIP39, SLIP39, Raw, with additional password.
  3. HD Key derivation (BIP32, CIP1852 standards, non standard Byron, Ledger Icarus, that contains
    • Master key generation: BIP32 (standard), SLIP10, SLIP23 (Semi standard), By PAth ron, Ledger, Some standard /w no password + non standards, or CIPXXX.Byron or imanigary CIPXXXX for Shelley mainnet specific or similar
    • Key derivation function: BIP32, BIP32-ED25519
    • Key identity: BIP32, RAW, None, etc.
    • Key serialisation: BIP32, None, CIPXXXX etc.
  4. Wallet Structure and addressing.
    • Path derivation: BIP32, BIP43, BIP44, CIPXXX
    • Address serialisation: BIP013, Byron Legacy, Byron, Shelley, or whatever names.
    • Address encoding/decoding: base58check, base58, bech32 etc.

So for standard Shelley it would be the following:

  1. BIP39.
  2. CIPXXXX
    • Master key generation: CIPXXXX as defined in the CIP
    • Key derivation function BIP32-ED25519 as defined in the CIP
    • Key identity: None or CIPXXX as defined in the CIP
    • Key serialisation: CIPXXXX as defined in the CIP for different type of keys.
  3. Wallet Structure
    • Path derivation standard: CIPXXXX, as defined in the CIP e.g. the m/1852'/1815'/0'/{0,1,2}
    • Address serialisation: None or CIPXXXXX as defined in the CIP for key export/import
    • Address encoding/decoding: base32

So, a wallet would have some well defined wallet standard/description and some other descriptions for backward compatibility for power users.

1 Like
5

This is new for me, thx. Following up.

6

For path derivation, we should have CIP e.g. CIP1852 or similar

CIP1852 is defined here. Itā€™s not in the CIP repo yet just because I never had time to update it, and also the wording of the rationale probably needs to change because it was originally designed for Jormungandr where we had ratio keys, but those arenā€™t available in Haskell Shelley.

1 Like
7

Yep, I read it back then and we had some discussion about it but you guys need to decide how to modularise these CIPs, i.e. what includes what, how and why, from a list similar to the (non-complete) list I wrote down above.

Also, I checked these new addresses and got reassured a bit as I complained some days or week back about storing the raw public keys in the blocks, and these different type of 28 bytes length hashes are really good candidates for them. But, but this should also have some CIPs, how theyā€™re created etc.

Even, probably a 20-byte length hash would be enough (at least for some type of addresses), but it depends on the all rigsā€™ hash rate that can brute force that 160 bit (and some other factors).

But, I would leave these to some different security experts to decide, as I am not one of them.

1 Like
8

Ok, I need to clear it a bit.

  1. For a single sig 160bits is fine.
    • SHA mining rigs cannot be repurposed for some other hashes e.g. RIPEMD160 or blake2b (with 160bit result)
  2. For multisig: the security of 160bit is only ~80bits, for 224 is ~112bits, so for multisig addresses 256 bit hashes should be used (but I am not an expert).