(HD) wallet backup. What about we re-standardize derivation path?

  1. A user coming from bitcoin.com or read.cash won’t lose their funds in a wallet that scans both paths.

  2. New wallets should simply follow the standard. The reason bitcoin.com didn’t was to make it easy to split coins through the fork.

  3. 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.

  4. Additional to 3, it’s trivial for a 0 wallet to implement scanning of both paths.

  5. 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.

2 Likes

insert appropriate Star Wars picture
This is the way.

2 Likes

Thanks Kallisti,

this is the first actaully rationally argued case for 145. Which is amazing in a thread this size.

Its a good argument, for sure. But it fails to add new information in that it doesn’t actually address the point of this thread: why not simply update that BIP and follow the most used key. Read the topic: “what about we re-standardize dervation path?”

So, you basically have a counter suggestion which is to say “we” can continue going down this road because if we keep going long enough we’ll beat the (still most popular) other wallet in wallet count.

That argument is going to leave this issue to grow for years to come and aim to “win” the race of wallet-count over the backs of the people you’re supposed to actually serve. With the excuse that you’ll make it easy for them, but screw the other side.

But, as you also correctly pointed out, dead horse… :man_shrugging:

Why are you ignoring the real issue with using the same derivation path for BTC and BCH?
The whole purpose with BIP44 is for sharing the same seeds across different chains and reusing keys in these cases are bad for privacy and I have literally demonstrated it to be the case with the “market leader” wallet above.

How did you come to this number?
I believe both Ledger and Trezor is using the 145 path for Bitcoin Cash but it’s AFAIK impossible to know how many of these wallets have any BCH.

Read his arguments again, especially this:
“Additional to 3, it’s trivial for a 0 wallet to implement scanning of both paths.”
This is the way to serve the users and by that I think (although I can’t speak for everyone) the discussion is resolved.

1 Like

Just because I come to a different conclusion does not mean I ignore facts on the table. I weighed them, I wrote about those facts here and elsewhere.

You using “why are you ignoring” is needlessly turning this into a personal thing, which has no place here. Stick to the facts and talk about the facts, not the man.

Thank you for your consideration.

FWIW, it’s the Trezor guys that drafted the BIP44 registry.

And @Tom: It’s way more reasonable for our devs to just use 145 than it is to try to change the BIP, which affects the ENTIRE crypto ecosystem, not just us.

Problem is already solved, we are running in circles here, again.

Please read up on the topic.

There is no issue here.

You cannot enforce any derivation path because there is no official governing body for Bitcoin Cash.

Read.Cash and Bitcoin.com will just keep using their derivation paths as it suits them. This is not going to change because you want it.

What you can do right now is convince people to use other, more privacy focused wallets, that will use a better derivation path.

And all modern wallets should scan for all popular derivation paths on seed import. As we already established, this is easy to code.

Problem solved.


Again, running in circles.