I think that as more and more awesome ecosystem wallets come online a Polkadot Standards Proposals (PSPs) that defines a derivation path standard for our ecosystem with detailed rational as to why we do that ala BIP44 and SIP44 is called for.
//<network name> and aldo //<network name>/<incrementing number> in prior iterations of Vault and perhaps the Polkadot extension wallet at least at one point was the default derivation path for any wallet created.
In the context of the Academy I put together a small subkey demo that follows the “standard” as I understood them via an older version of the docs on that CLI tool.
I think an (unspoken/undocumented?) standard is now the account being the root key without any derivation at all. It is in subkey now for example.
Our SS58 registry is effectively SLIP44 for Polkdot AFAIK, but also I am not sure it’s really understood how to use and why it’s needed to have the same keys map to different accounts by end users very well, including me .
With all wallets defining how to handle derivation path defaults ad-hoc, I doubt any strong interoperability would be possible. IMHO compatibility/portability for our wallets with the same secret recovery information by default would be a a big win for everyone. For example ledger cannot interoperate with other wallets quite sadly for an semi-related reason, and users hate that interoperability isn’t possible when they want/need it.[1]
Would you desire and support a PSP to define a standard?
Of course the security implications of migration need to be considered, but not what is demanded by users in my experience, including me. ↩︎
I wrote a suggestion quite a few years ago; pretty sure it was on the wiki but doesn’t seem to be there now.
Having had to muddle with dozens of scraps of paper for various seed phrases over the years, I am 100% against using the root key (i.e. the secret key immediately derivable from the seed-phrase) as an account. I have not used any software which has attempted to standardise this, but I would send a clearly worded piece of correspondance to any ecosystem teams if I did see it. To be perfectly honest, I think the basis of what we had in Signer v4 was fine; the biggest issue was forming a convention on exactly what path should be used to create the account (or accounts) for any given network.
I would propose a few:
//network: Primary high-security account for network, named according to the network’s chain spec. //network//0, //network//1, …: Secondary high-security accounts for network. //network//pub: Primary high-security public account for network (i.e. one which the user is happy to be associated with their “real” ID). //network//hot: Primary low-security account for network (e.g. one whose secret key the user exports from the Vault to carry on an internet-connected device).
Realistically, simple wallets might only expose their user to the first of these, but if the standard is used then the seed phrase can be exported between wallets and will readily work.
I see no great need to have different seed phrases for different networks; indeed as we move into having thousands of chains and the distinction between a “network” and a “contract” becomes increasingly blurred, then I think it will become obvious that just as we will tend to store all seeds on a single device, we will branch all keys off a single seed.
As for Ledger I fear it’s just not a device which is well-suited to Polkadot in general with its upgradability, different chains and transaction types. It’s designed largely for Bitcoin clones and works reasonably for that use-case. It’s definitely not a great fit for general Web3 usage and while there’s an argument to be made in favour of pan-industry standardisation, I’m not super convinced about straightjacking the ecosystem with a Bitcoin-centric standard.
@bjorn@joepetrowski , Gav, Eva & Josh - Bjorn Markus Jakobsson & Kier Finlow Bates appear to be submitting blanket patent applications. I would imagine a lot of the work infringes on Parity Technologies’ contributions to the space. It is overwhelming how many they are submitting in quick succession. Probably enough to hinder adoption unless counterclaims are made.
There is one thing that I don’t quite understand, though:
Root-Public key should be shown in UI as an SS58 with a prefix index of 1 (BareSr25519) or 3 (BareEd25519) - depending on crypto used.
What’s the purpose of displaying the root public key in the UI?
It’s clearly not for receiving funds, correct? So, is it so that the user can sign data with the “Root Secret” and then provide the Root-Public key to verify the signature?
I’m clearly missing something in here. I would really appreciate some guidance on this
The public root is what identifies the hierarchy. If you’re ever moving accounts between devices or restoring an old account tree, then it’s there to confirm that you’re putting in the right seed phrase.
It’s not (or at least shouldn’t be) an account itself, so it should use a neutral SS58 prefix and identicon.
.