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

Wallets
#15

There is already a standard. Some have followed it and some hasn’t which is understandable due to the different trade-offs: mainly key/address re-use vs ease of spending forked coins from the BTC/BCH split. Changing the standard doesn’t really help since we already have five years of BCH wallets created with different derivation path(s) and IMHO we should just bite the bullet and realize that we can not reach 100% unity on all wallets using the same path. The cat is out of the bag and has been running around for half a decade.

The fact that the “market leader” with a commercial wallet targeted for non-technical people doesn’t scan a couple of commons paths at seed import is quite frankly their problem and I guess their own customer support would push the issue internally if enough customer thinks they lost money. It’s not rocket science to implement it (I would know since I wrote the EC scanner…)

2 Likes
#16

You need to understand that your point is totally valid and you are completely right here, however you will not get anywhere with this attitude.

I know from example, because I also have an aggressive “texas ranger” attitude by default, but I keep working on myself to only use it in emergencies/when there is no other choice.

The way to approach this problem is maybe if you propose to them that you will improve their code for a moderate amount of BCH per hour of your work. Then do the same with read.cash - ask them if they wouldn’t like somebody to fix their problem at a reasonable price.

This way you will be seen not as an aggressor who wants to break their business model and/or make them look like fools, but instead you will be seen as a friend or at least a contractor who can fix their problems for them.

In general, they (Bitcoin.com/Read.cash) have already established an “industry standard” by not following a previous standard but instead “forcing the way” using other means.

And now we ended up in this unpleasant situation.

Nobody likes it, sure, I agree that it is less than ideal, but I also understand how humanity works and why the proposition to enforce BIP145 using force is not going to work.

Deal with it: Enforcing BIP145 is absolutely NOT going to work when we already have had industry leaders using other standard for years and also we have no strong reason that could make them change their mind.

#17

I’m not enforcing anything on anyone nor am I trying to change the mind on anyone (besides people that think it’s a good idea to flip-flop paths).
There are real pros and cons in using the same path as BTC or not and I fully expect wallets to have done their own analysis of the situation and reached the most suitable solution.

I don’t really know the point of this whole discussion since old wallets with different derivation paths will be available for the foreseeable future and has to be dealt with even if all known BCH software by magic synchronously changed to the same default path over night.

I guess the market leaders hasn’t perceived the problem as big enough to warrant the development of a scanning feature. Realistically that is simpler then the mess that their users would experiencing if default paths would be changed.

#18

We can agree that all popular wallets should scan the top 2 or top 4 derivation paths by default.

Of what I understand, this is not even difficult to code.

#19

SLP on the same path as BCH would be a great way of burning tokens. Imagine restoring the UTXOs on that path in a non-SLP aware wallet: the user would literally just see some dust transaction and upon consolidating those all tokens would go up in smoke.

2 Likes
#20

You are not. Also I am not accusing you. I am speaking in the general direction of every topic participant.

But this you are. Discussion does this to people you know. Us discussing it here will change some minds and perhaps can even change the future for next generations after Bitcoin Cash becomes global dominant currency.

Your opinion is important.

#21

I’m curious. Does anyone know where this “standard” is documented? People keep referring to BIPs, but the bips repo under bitcoin (that is BTC) is the official place where BIPs are maintained and there it is not specified. (search results). I also checked the bitcoin-specification, nothing there either.

But, even if it was somehow officially specified, there is something called a De facto standard - Wikipedia. Which is most definitely what the ‘0’ derivation path is for Bitcoin Cash. (now re-read that XKCD above). So this should be a competition of two standards, not one rogue that has to be called to heel.

Anyway, the market will decide on this one too. Unfortunatly the users have to suffer in the meantime. Not my circus, though.

#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