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

Wallets
#30

Simple. Because if I had a HD wallet, I would just have stayed on the same words, possibly.

And then, my transaction history could have been easily tracked on both chains (and all other forked chains like BSV and eCash).

Most users will just do this. And this is a bad privacy practice.

Exactly why wallet developers changed derivation to BIP145.

But I think we are running in circles here. This is a non-issue.

Let’s just lobby all wallet developers to add pre-scanning of all common derivation paths on wallet import and have this issue solved. Of what I understand, this is a relatively simple thing to do [sb correct me if wrong].

So why not just do it and solve this matter once and for all instead of spending valuable time on useless discussions that don’t seem to be leading anywhere?

#31

I wasn’t going to post anything else in this thread but somehow you managed to go full circle here and I would suggest that you do the following experiment:

  • Install Bitcoin dot com wallet.
  • Open it and go to the receive tab on the BCH wallet.
  • Copy the address into blockchair dot com and open the Bitcoin Cash information page for that address.
  • In the wallet app go the the receiving tab of the BTC wallet.
  • Compare the BTC address with the “Legacy” field on the blockchair page. Voila! The addresses are identical!
#32

Ha, the default created one in bitcoin,com wallet reuses the phrase? Good catch!

And some posts back someone was claiming that the bitcoin,com team really thought things through when they decided to keep the BTC path.

#33

That someone was me.

Indeed they did.

Obviously their intention was to make it easier for the user. Privacy was not taken into consideration here.

When the user now copies wrong address (BTC->BCH or reverse) by mistake, and inputs the address into an exchange to withdraw, he will still receive his BTC/BCH without problem. I would guess this feature alone saved Bitcoin.com millions in technical support.

They apparently succeeded here. Bitcoin.com is most probably the easiest to use wallet right mow. Also the most popular.

#34

They apparently succeeded here. Bitcoin.com is most probably the easiest to use wallet right mow. Also the most popular.

We’re running in circles. The topic was opened by @tom acknowledging that, and suggested that all other wallets should follow bitcoin.com’s lead and use '0 for the path.

Problem is, whichever wallet would make the change would be burdened with supporting their own users who made wallets before the change, and would have to support 2 paths indefinitely. So if they will have to support both paths anyway then why should they change their default path when it won’t matter if its '0 or '145 since they’ll be capable of importing automatically from either one?

IMO wallets should automatically check both '0 and '145 paths when importing, and continue to use their preferred path for new wallets.

Question is how to handle imports where coins are found on both paths? Should wallets ask the user to choose a path and offer a sweep from the other one? Should wallets nudge user to switch to wallet’s default path?

2 Likes
#35

I know, that’s literally what I said.

There is no problem to solve here, a nearly perfect solution has been already provided. Nothing more to do here.

Should I start posting cat pictures?

#36

and;

This is likely the end result we’ll end up with, I agree. Which is exactly the outcome of the first point. That ‘support indefinitely’ part. To allow importing both of them.

And here is the rub, this is the ‘ego’ playing, pointing to “we were first” (literally a quote). Because weather they change or not, they will have to support both indefinitely.

Two choices, one that keeps perpetuating the current problem. The second (the one I asked to be considered here) is to follow the market leader and actually solve the end-users problem structurally.

Which is why I said that we don’t have to do anything. If the leaders of wallets are salty over this, and they prioritize their own ego’s over the funds of their users wallets, the end result is them losing even more market share to the point that the problem solves itself.

So, I closed this issue already iin reply 5, it was a nice discussion afterwards to get all the details on the table. But the end result stays. Either those minority wallets adopt (for the sake of their users) of they keep losing marketshare.

1 Like
#37

We can do something. We can post an “official community recommendation” to support both derivation methods on import.

This should solve all problems.

After that, wallets can use whichever standard they choose, it won’t matter.

1 Like
#38

I’m catching up on this topic again and this point doesn’t align with my reading. BIP44 appears to specify “registered coin types”: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registered_coin_types and points to https://github.com/satoshilabs/slips/blob/master/slip-0044.md
Which, amongst other coins, nominates Bitcoin Cash as “145” and Bitcoin (core) as “0”?
Notably Bitcoin Cash was “registered” on Jul 24, 2017.

I appreciate the discussion has moved away from “which path is right/wrong” and taken the direction of “scan both paths anyway”, but I feel that the content of BIP44 disagrees with your statement that “BIP44 doesn’t state Bitcoin Cash should have the number 145”. How do you interpret it that way?

#39

2023 now:

Stack Wallet uses 145: https://github.com/cypherstack/stack_wallet/blob/main/lib/services/coins/bitcoincash/bitcoincash_wallet.dart#L75

Edge uses 145: https://github.com/EdgeApp/edge-core-js/blob/master/docs/key-formats.md?plain=1#L98

Melis is using different derivation paths per coin, but passes them around a strings like “btc” and “bch”, and I can’t find their actual derivation across their many repositories - very likely also doing 145.

#40

I just want to add another data point to this thread. After reading this thread and discussing elsewhere, we (the Selene Wallet developers) have decided to go with the “standard” m’/44’/145’/0 derivation path as defined by BIP-44.

#41

The facts haven’t changed since this post was opened. Still about 90% of the existing BCH people have gotten a BCH wallet with a seed that uses the zero path. :man_shrugging:

#42

  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
#43

insert appropriate Star Wars picture
This is the way.

2 Likes
#44

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:

#45

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
#46

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.

#47

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.

#48

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

Please read up on the topic.

#49

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.