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):
- āw/sā: seed generation e.g. BIP39
- 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
- Seed Generation (e.g. BIP39, SLIP39 etc) including plausible deniability features
- 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).
- 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.