[Awareness/Proposal] The multitude of different "derivation paths" in BIP32 Bitcoin wallets causes incompatibility all around when it comes to wallet seed restore operation for non-tech-savy users.

NOTE: Purpose of this post is to draw attention to a possibility for improving Bitcoin and its wallet ecosystem constructively, so please do not blindly hate and downvote based on a false understanding that this is harmful criticisms. It is not. Negating a fruitful constructive dialogue would be harmful.

Nowadays different BIP32 wallets use different derivation paths. This means that even with a properly backupped seed a non-tech-savy user may see zero balance when restoring this seed with another wallet even if that wallet advertises to use the same BIP32-based hierarchical deterministic wallet.

Reason for this "mess" is partly historical, partly programmer lazyness, partly proprietariness:
BIP32 and hierarchical wallet methods have evolved over time, and depending when the wallet came out, different derivation paths were used. Some wallet programmers seem to prefer short derivation paths not following BIP32 recommendations apparently to save some lines of code in implementation efforts. Again other wallets find special reasons for using proprietary non-standard derivation paths for special purposes (e.g. Samourai).

See https://walletsrecovery.org for details.

Nowadays, derivation paths most common and recommended by BIP32 are

• m/44'/0'/0'
• m/49'/0'/0'
• m/84'/0'/0'

for the three bitcoin address formats, respectively.

But others still exist for legacy reasons, like

• m/0' (e.g. BRD wallet, Multibit HD wallet)
• m/0'/0' (bitcoin core, historically)
• m/44'/0'/n' (blockchain.com proprietary)
• m/44'/n'/0' (n=0, 1, 133, 145)
• m/84'/0'/n'
• m/49/0/X (note the missing ' everywhere!)
• m/47'/0'/0'
• m/45'/...
• m/48'/...

Note that n and X above denote variables from 0 to 2147483647, whereas m is a fixed letter that stands for "master". The ' stands for "hardened" and is also written as h or H is some implementations.

Since the number on each derivation path level can go from 0 to 2147483647 and can be with or without the ' , and since there can be an (almost?) arbitrary number of levels, the number of derivation paths is practically endless, and checking all of them would take an astronomical amount of times longer than the age of the universe even with all computer power on earth. Therefore it is not possible for any wallet to check all possible derivation paths when the user restores a wallet seed.

Therefore we can assume that wallets only check for "their own" derivation path(s) when a wallet seed is restored, and this means that they might be missing bitcoins if the seed was formerly used in another wallet SW/HW.

We do not know how BIP32 will evolve in the future. Maybe in 10 years from now today's mainstream derivation paths will be obsolete and not checked any more by default by standard wallets.

Therefore, everybody making a wallet seed backup is also strongly advised to back up the derivation path and the algorithm. Or at least noting next to the seed which wallet SW and which wallet version this seed was used with.

From wallet SW and BIP standardisation point of view it is desirable that

• (a) A new "BIP nnn" is created that defines sets of derivation paths (like the ones listed above) that are used/checked for a given wallet seed, and
• (b1) A wallet SW that calls itself "BIP nnn version R compliant for restore" must check for all these derivation paths upon wallet seed restore, such that no funds are lost or missed, and
• (b2) A wallet SW that calls itself "BIP nnn version U compliant for own seed usage" must guarantee not to use other derivation paths than those listed in "BIP nnn ver. U when operating on a self generated seed.
• (b3) A wallet SW should also display the BIP nnn version U for every wallet in use such that the user knows that for a later restore he needs a wallet SW whose BIP nnn version R for restore is at least >= U.

W.r.t. (a), this BIP nnn should be updated (i.e. the list of derivation paths extended) whenever a wallet wants to use derivation paths not yet in this list. Then this wallet should apply for a new BIP nnn version.

Then the BIP nnn should be versioned every time the set of seeds is enhanced.

Then, w.r.t. (b), a wallet SW/HW can advertise to be "compliant to BIP nnn version R for seed restoration" (higher R = better for compatibility) and "compliant to BIP nnn version U" w.r.t. derivation path usage for self-generated seeds (lower U = better for compatibility).