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

Wallets
#22

Even if all BCH wallets would’ve continued on the BTC derivation path users would’ve suffered – just in a slightly more devious way where privacy would potentially be degraded instead. Pros and cons, different drawbacks, pick your poison and so on.

I can totally see why Bitcoin dot com did what they did and why they won’t change the default (hint: at the time of the split they already had a sizeable user base with cons on that path). I can also see why new (BCH only!) software would use the same path for ease of portability. But that doesn’t take away the privacy issues that might occur if the same keys is used for different coins, which is pretty much the reason for BIP-44 to exists anyway and a problem that is solved.

Wallet developers should just pick the one they deem proper and go with it and since it is a free choice we will always have several different ones out in the wild. The good news is that wallet developers can help users by scanning paths on import which pretty much removes the head ache from that wallets users.

Didn’t we have this discussion 5 years ago?

2 Likes
#23

BIP-44

For those that consider Bitcoin (BTC) and Bitcoin Cash (BCH) to be different coin_types it makes sense the value would differ.

#24

WOW, so there is a serious drawback from using the old derivation path after all?

It would have helped more if you said it in a clear way in your first reply. That would save a lot of time, probably.

This is a very strong argument that was completely missing in this discussion, thank you.

We had? I was not included in it, I guess.

So it would appear that wallets can choose either of these 2 derivation paths [the wallets that care about privacy more will choose BIP145 of course] and just scan for all popular derivation paths when importing key words.

This looks like a complete solution to both problems (privacy included).

#25

It’s not even 2 competing standards, it’s 2 competing interpretations of the same BIP44 standard :smiley: The derivation algorithm is the same, the 2 “standards” differ in just one constant (the coin_type'), but it makes all the difference.

1 Like
#26

Looks like tempest-in-a-teapot situation to me, then.

Let’s just

  • Post a general “official community recommendation” not to use 0 derivation path for privacy reasons
  • Add automatic scanning of multiple popular derivation paths on wallet import in all popular wallets. [AFAIR it is super easy to do]

and be done with it.

1 Like
#27

Just in the vain of being brutally honest and care only about users, being practical and not about ego or vanity:

  1. the privacy ‘issue’ is bogus. There is not any real world actual usecase that triggers the issue. Anyone stating that a seed is reused between chains is basing that on a hypothetical and not a real life scenario.

  2. The BIP 44 does in actual fact NOT state that Bitcoin Cash should have the number 145. Anyone claiming that they are following a standard BIP is lying.
    What really happened is that the BIP gives the opportunity and hint to pick a different number. It doesn’t specify, it does not demand you do. It certainly didn’t specify the actually picked number. (agreed with BCA on this).
    So anyone claiming that those various wallets are just following specs are lying to themselves, and their customers.

Sorry if this offends any feelings, if people are lying to themselves they are out of luck, I’m not going to enable them. And everyone should question if they are doing this enabling and if they are actually helping Bitcoin Cash.

#28

Hmmm…

Looks to me it is a real scenario that could easily have happened multiple times to multiple people.

I mean if I had a HD wallet before August 2017, I would probably just import it again right away on BCH chain to get my BCH.

Luckily I had not.

But people are lazy [and sometimes incompetent]. I would not be surprised if they used the same words multiple times on multiple chains for convenience reasons. In such a case, there actually would be a privacy loss incurred.

So there definitely is or at least was a privacy issue.

#29

Splitting your coin required you to exactly that, so not sure why you say you were lucky… But this is not really the topic at hand. Splitting is always messy and each split will need handholding based on circumstances.

Back to HD wallets;
There is in actual fact not a single wallet that allows you to use one wallet for multiple chains. There is also not a single wallet that has a feature like “duplicate seed to [chain-name]”.

Instead all HD wallets that are started on some chain are created by the wallet having some randomness. It is not a supported usecase.

Now, I’m sure you can come up with some work-around, forcing the issue. Which is why I wrote: Anyone stating that a seed is reused between chains is basing that on a hypothetical and not a real life scenario.

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