-
A user coming from bitcoin.com or read.cash won’t lose their funds in a wallet that scans both paths.
-
New wallets should simply follow the standard. The reason bitcoin.com didn’t was to make it easy to split coins through the fork.
-
A user who exports their seed from a 145 wallet will only have issues importing into the bitcoin.com wallet - which frankly, is bitcoin.com’s problem. Let their customer support and dev teams deal with their technical debt. Same with read.cash and memo.cash.
-
Additional to 3, it’s trivial for a 0 wallet to implement scanning of both paths.
-
As long as new wallets choose the 0 path instead of the documented, standardized 145 path, the problem described in OP will only get worse.
Conclusion: just use 145. There’s no reason to continue beating this horse but some form of rationale for the decision for Selene to use 145 was requested.
Edit: (HD) wallet backup. What about we re-standardize derivation path? - #4 by tom
Most wallet apps use 145.
Most generated wallets MAY be created by bitcoin.com or read.cash but we really have no way to properly measure that.
It doesn’t matter if there’s a higher “wallet count” on 0 if new wallet apps scan both and if new wallets are created on 145 going forward.
Eventually the vast majority of generated wallets will be on 145. Again, the deviation from the standard is entirely bitcoin.com’s problem as long as all of the rest of the wallet eco system allows import of both paths, because then end users are unaffected and they don’t even need to understand what a derivation path is.