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

Wallets
#1

With the release of a nice printable paper where people can write down their 12 word seed, the design of ‘derivation paths’ came up.

Todays reality is that the derivation path is the second detail requires for importing a wallet from a seed-phrase. The idea has always been that a derivation path was reused accross all wallets (for a chain) making this something normal people can ignore.
But, todays reality is that the most used wallet does not have the same derivation path that other Bitcoin Cash wallets use.

And this makes it just a mess where a complex path, which normal users could just ignore, now becomes an obstacle to being able to move between wallets. The exodus wallet help page bluntly says that its not possible to import between wallets.

Polling here to have a bit of a feeling for what others think; we probably all agree that inter-wallet compatibility of backups is important and it should "just work"™.

My personal thought goes toward just re-defininig the “bitcoin cash derivation path” to be the one that most bitcoin cash wallets use. With most I’m counting the market leader, or amount of wallets created. In other words, make clear that we are using what the bitcoin,com wallet is using. Where we means the decentralized set of people behind Bitcoin Cash.

In effect the path is a rather irrelevant thing to practically all users. It doesn’t really add much to differ between chains, even. SLP having an official different one makes no sense to me. BTC using a different one from BCH is optimizing for the 0.1% of the users. It makes no sense from a UX point of view.

So, maybe we can just agree to all use the same one. For instance on the one most existing wallets use: m/44'/0'/0'

1 Like
CHIP 2023-01 Backup: wallet offline backup formats
Wallet Backup Standard
#2

This seems like a good idea in general, I would also add a strict naming system, where we mark each known derivation system with an user-friendly name that is easy to remember, recognize and differentiate, like:

  • “Bitcoin Cash derivation path (2022)”: m/44'/0'/0'
  • “SLP derivation path”: [something else]
  • “BTC derivation path”: [something else else]
  • “Legacy derivation path”: [something else else else]

Of course, all BCH wallets should choose the first one and warn users against using any other for safety reasons (as in maintaining low blood pressure when something goes wrong).

But there will be problems. There always are. The first problem could be how to avoid “standarized XCKD standards situation”:

3 Likes
#3

My personal opinion is that BIP44 is a valuable standard and should be promoted. Bitcoin.com have caused an issue by not following that standard; It’s one way to “lock-in” users who will have issues trying to move to another wallet. It is for this reason that quite a number of wallet developers have adopted a known and established standard, promoting user choice. My standard procedure nowadays is to advise users who backup wallets to also record the derivation path along with the mnemonic, otherwise they risk issues if restoring to another wallet.
In short I would rather lobby Bitcoin.com to adopt the industry standard and they can manage the technical debt they have incurred and the problem that might cause their users.

2 Likes
#4

I do like the idea to avoid creating a new standard. Ideally we pick the most used one and thus remove one instead of adding.

So the only difference seems to be a fight between the chain-id. Either wallets use m/44'/145' or they use m/44'/0'.

  • Electron Cash uses 145

  • Bitpay uses 145 (in their open source repo).

  • Coinomi uses 145

  • Paytaca uses 145

  • Bitcoin,com uses 0

  • read,cash / noise,cash uses 0

Edge and Melis I emailed, will update as they come in.

Any changes made to unify this, if possible, will have to take into account the amount of actual wallets (people) created and weather those wallets provide a scanning feature. For instance the EC wallet scans several derivation paths for any hits on usage and is thus able to import anything.

1 Like
#6

Bitcoin.com has chosen the legacy Bitcoin derivation path (m/44’/0’/0’) for both BTC and BCH, most likely for convenience…ignoring the standard for BCH (m/44’/145’/0’). They simply didn’t follow the standard and that’s a bad precedent and a technical debt they should have addressed.

I’m in favor of sticking to the current standard in Paytaca, just like what other wallets do. However, since many users of our wallet will be coming from Bitcoin.com, we will have to implement a solution to allow seed phrase import using the m/44’/0’/0 derivation path.

4 Likes
#7

The outreach is getting rather saltly responses, this may be a sore point for some. :man_shrugging:

Like Imaginary speaking for BCHN dismissing this with;

in any case, i’m not sure switching derivation path is high on the to-do list given bigger ticket items people are working on.

Jonald, the owner of Electron Cash came back with this

I think its silly to change it now after 5 years. That’s one man’s opinion.

Been getting the brunt of said salty-ness today, so I’ll stop asking around for opinions / options and let someone else try to improve the situation for users.

#8

all wallets should scan for common paths when importing.

2 Likes
#9

@pchandle

Disclaimer: I am not a Bitcoin.com or Read.cash supporter, I will explain my stance and reasoning in thorough detail below.

In general, I am all in for establishing - even with some amount of force used - standards that make it more convenient for the userbase to use a product.

The problem here is, that now, that I have understood herd the nature of the populace at large, I don’t think that will work.

The underlying base problem here (and also why @tom is right that we should establish the most used way, not the absolute best as a standard) is because the populace does not follow reason, logic, wisdom or any of such cruft. The people follow other people and especially they follow what leaders do or tell them to do.

This mechanic is precisely the mechanic that creates network effect thorough history.

The situation we are dealing with is that Bitcoin.com, together with read.cash/noise.case - the industry leaders [or herd’s alphas] right now, have already creatred a huge network effect for the 0 derivation path. And whether we like it or not, Bitcoin.com together with that other blog services create probably huge chunk (if not most) of the BCH network traffic right now.

So even if we try to push another derivation standard as default, unless we have a VERY good reason (like the old derivation is highly technically inferior or is a security risk), this is never going to work.

People won’t follow just because we tell them that “listen, this thing is reasonable, it works, it is better, you should do it”. This is not how life and mankind in general works. People will just keep using the established solution that has huge network effect and works for them. They will tell their friends and their friends will tell their friends, and the network effect will just keep increasing.

Unless there is an extremely good reason, pushing to standarize other derivation path than the most used one is just pointless waste of time that will ultimately fail.

Can you define the issue Bitcoin.com has caused (other than not following a earlier-decided-upon way of doing things). I mean we need to define what exactly does using that “bad” derivation path does to users.

Is there any inconvenience? Technical issues? Bugs? Technical Debt? Security issues? Please give me a very concrete answer, precisely what is the problem.

Well, that depends how you look at it. Either they have not followed a standard, or they created a new, better “standard” that is more convenient for the users, because most users right now use that standard - which created a network effect for that standard and that network effect will make it more convenient for most user to safely store their funds.

Of course, using known and established, and especially - tehcnically superior - standard is the best, most of the time.

But I don’t think this is the time.

Yeah, and this is where we failed. We created a (perhaps?) unnecessary complexity for users, assuming that BIP44/145 is not significantly technically better than 0.

Yeah, this is not going to work.

I will tell you why.

Bitcoin.com, together with read.cash / noise.cash most probably already have bigger userbase than the rest of the ecosystem combined. Crypto is already too complex for 95% of the populace as it is and they are not going to risk changing their established standard and hurting their userbase without a VERY good (“we should standarize for convenience” does not count) reason.

#10

I don’t remember where, when, and how I managed to get information about this, but I heard that Bitcoin.com stuck with m/44'/0' to decrease people mistakenly sending BCH to their BTC addresses and vice versa. If you created a Bitcoin.com wallet for the first time, your BCH and BTC wallets have the same 12-word seed phrase.

Read.cash, if I recall correctly, uses m/44'/0' so it can be added to Bitcoin.com wallets.

1 Like
#11

This would seem like a good way to establish an ever-increasing network effect in general.

Clearly somebody gave it a lot of thought.

#12

That seems backwards. I suspect the reason they stuck with the same derivation paths on both chains was so the user wouldn’t need to migrate any coins held during the 1st August 2017 split and just have two wallets with respective coin and full history.
Wallets created after the split does obviously not have this problem and the drawback of using the same path on different coins is key reuse.

My 2 cent in this: Wallets should scan the most common paths during import and the user should really not have to deal with derivation paths…

4 Likes
#13

Wallets should scan the most common paths during import and the user should really not have to deal with derivation paths…

This. It’s not like there’s a zillion derivation paths. There are 2. One that adheres to the standard, and one that uses BTC’s path.

4 Likes
#14

This seems like the obvious solution or workaround.

Having a standarized derivation path is also a nice addon though, so tom is not wrong here.

1 Like
#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.