It would be useful to have list of requirements for a future replacement of the standards around hierarchical deterministic wallets and other uses of deriving keys from a mnemonic. Let me know if this is not the right place.
In order to turn it into a BIP / SLIP it needs more feedback and I'll need to make it bit less opinionated :-)
A good place to start is the mnemonic word list. @Arachnid suggested several improvements a while ago (see below). Even though an updated word list will have overlap with the BIP39 list, new mnemonics can be generated in such a way to guarantee incompatibility with existing wallets. This intentional incompatibility provides an opportunity to change other rules.
I do not believe this is urgent, so there's time to do this thoroughly and develop a standard that last for a while.
Word list and incompatibility rule
Criteria @Arachnid used in his word list generator draft:
- all words are 4-8 characters
- all 4-character prefixes are unique (very useful for hardware wallets)
- no two words have edit distance < 2
Wallets need to be able to distinguish between the old and new standard, so un-upgraded BIP 39 wallets should consider all new mnemonics invalid. At the same time, some new wallets may not wish to support BIP39. They shouldn't be burdened with storing the old word list.
A solution is to sort the new word list such that reused words appear first. When generating a mnemonic, at least one new word must be present. A wallet only needs to know the index of the last BIP39 overlapping word. They reject a proposed mnemonic if none of the elements use a word with a higher index.
Other coins and versioning
BIP 44 is too detailed. E.g. it doesn't make much sense for non-UTXO coins such as Ethereum. It's also not very flexible, leading to the creation of BIP49 to add SegWit support. BIP43 on the other hand is too permissive. This makes it difficult for wallets to properly advertise their compatibility.
The community for each coin is probably most suited to figure out their own derivation scheme below the coin type level. I propose the following rules for coins to be accepted into the standard and for wallets to be able to claim compatibility.
- the coin needs to have a BIP-like process and their derivation must be specified in such a "BIP" (which in turn could be as simple as "same as Bitcoin but with different coin type")
- a wallet which claims to support this new SLIP-[X] standard can choose which coins to support
- if a wallet claims to support SLIP-[X], then for each coin it supports, it must support this standard specify otherwise
- SLIP-[X] starts at version 1.0 and wallets should communicate this version
- New coin types can be added without a new version
- Once a coin is accepted, it must wait for a new SLIP-[X] before allowing coins to be deposited on an address where existing wallets would not look
- wallets which claim to be compatible with version N are assumed to be compatible for all coins they support, unless otherwise specified
- coins may not change their standard in such a way that new wallets don't look in places where old wallets may have left coins
See also SLIP-0010 for non-secp256k1 coins.
GAP limit, etc
The rules for which addresses to scan should be coin specific.
Bitcoin
This discussion might be more appropriate for a BIP proposal, but I'm just putting it out there.
In my own experience the current limit of 20 has downsides. It may be a reasonable performance trade-off, but this should be evaluated.
There is often a delay between when a wallet user sends an address and when they receive payment. Sometimes they never receive payment. There are services such as exchanges which require you to give them an address, but you may end up never using it. For privacy reasons a wallet should not reuse such an address anywhere else.
As with BIP 44, change addresses don't need a GAP limit. Unless someone objects.
It would be a better user experience is empty accounts can be allowed, e.g. max 3 (again, assuming there's no unacceptable performance issue).
Perhaps by the time this standard goes live, all wallets default to SegWit. But if not, I suggest that when a wallet scans:
- the receive chain: for each index, check the P2PKH address first. If nothing is found, check the P2SH-P2WPKH address. Once it finds coins on a P2SH-P2WPKH address, it should only check the P2SH-P2WPKH address moving forward
- a separate bech32 receive chain. Since a wallet user needs to interact with older wallets, having a separate chain might be more practical then checking P2SH-P2WPKH and bech32 variants for each index
- one change chain: for each index, check the P2PKH first, then the P2SH-P2WPKH address, then the bech32 address. Stop checking P2WPKH once you find a P2SH-P2WPKH address, stop checking that once you find a bech32 address
Ethereum
Again, more of an EIP discussion, but just one thought: consider hardened derivation for each independent "account". Private keys can be exported and this is often useful when different wallets have strongly differentiated features and development is in flux.
Mnemonic to a seed derivation
Can this can be improved? @sipa might have some ideas regarding error correction. Representing the words as integer values rather than literal strings might add more flexibility. I like how bech32 allows a wallet to pinpoint the location of a typo. Similarly it would be nice if it can pinpoint which word is wrong and suggest the right one. For 12 word mnemonics it's surprisingly easy to type a wrong word and still get a valid mnemonic (but an empty wallet).
The minimum number of words could also be reconsidered, but there is a trade-off regarding the likeliness that someone actually writes it down.
Encryption
12-24 word mnemonics are great for new users, but they're not great if someone gets their hand on your piece of paper. It would be nice if the seed can also be exported in a BIP38-like encrypted fashion, perhaps printed as a QR code. More generally, it should be possible to take advantage of hierarchical deterministic wallets without having to use the mnemonic.
Account / address (hardened) derivation
Can this be improved?
I vaguely remember some Bitcoin Core developers having doubts . @luke-jr do you remember who / why?
Duress passphrase
Personally I'm skeptical about this feature and I think it just confuses people. For duress, wouldn't it be better for software to suggest a slight variant of the mnemonic that's easy enough to remember?
Removing that feature would allow more flexibly in the derivation algorithm.
Other languages
I don't think it's a good idea to map word lists in other languages directly to the seed. This could create accidental vendor lock-in if only one wallet supports a certain language. I suggest mapping each word to English or directly to an integer value. It doesn't have to be the same meaning.
If a foreign language mnemonic supporting wallet ever becomes abandoned, the community can create a printable sheet with the mapping of each foreign word to the corresponding English word (again, meanings don't have to match at all).
In addition to a list of universal criteria, it may be useful to have an approval process for each new language. For example some sort of testimony from a linguist, or a native speaker with significant experience in bitcoin. Every language has its quirks which leads to things to avoid (e.g. tons of homonyms in Mandarin) and things to embrace (e.g. many 2 character words in Mandarin).
Other purposes
E.g.:
- password generation
- pointing to data on a distributed filesystem (hash of public key points to a resource, private key decrypts it)
- etc
There should be a way to plug these new applications in. Perhaps through redefining "coin type" as "coin or application type"?
Name
I would suggest giving this standard a name that's as easy to recognize as USB. BIP44 caught on a little bit within the bitcoin tech savvy community, but it's not great to have a name tied to a specific BIP/SLIP number, even with versioning.
Other issues?
What else should be considered?