search

bitpay / wallet

Bitpay Wallet (formerly Copay) is a secure Bitcoin and other crypto currencies wallet platform for both desktop and mobile devices.
http://bitpay.com/wallet
MIT License
3.82k stars 1.74k forks source link

Bitcoin Cash: Derivation path confusion and proposed fixes #7216

Open fortran77 opened 7 years ago

fortran77 commented 7 years ago

Currently, some wallet software uses a derivation path of m/44'/0'/0' for Bitcoin Cash and some uses m/44'/145'/0'.

Coinomi by default uses m/44'/145'/0' but allows the user to manually specify m/44'/0'/0'. If the user has manually specified m/44'/0'/0', Coinomi automatically includes the label m/44'/0'/0' as part of the wallet name. This way, we can always tell when a non-default derivation path is in use (good.) (They actually use the slightly nonstandard string M/44H/0H/0H which is still understandable.)

Electron Cash provides a check-box to enable the use of m/44'/145'/0' (good) but calls it “Coin145” (questionable), If the box is not checked, m/44'/0'/0' is used. Once the wallet has been created there is no way for the user to tell which derivation path is in use (bad).

Ledger's Chrome app supports both m/44'/0'/0' and m/44'/145'/0', but they never tell the user this. Instead they label the use of m/44'/0'/0' as “Main”, and the use of m/44'/145'/0' as “Split”. So they tell the user what they are doing, but in words that will make no sense to anybody (bad).

The Copay, BitPay, and the forked Bitcoin.com wallet software all uses m/44'/0'/0'. None of it allows the user to specify m/44'/145'/0' (bad). The user can look up wallet information and find the derivation path, but it takes some effort.

Which derivation path is the correct one to use depends on your goals. If the goal is to make it easy for users to recover their forked Bitcoin Cash, then using m/44'/0'/0' achieves that. If the goal is for each cryptocurrency to have its own independent address space, in keeping with both the letter and the spirit of BIP44, then m/44'/145'/0' is more correct.

So here is what I think needs to happen.

  1. All the wallet software providers should make it easy to use m/44'/0'/0', because it's needed to recover forked Bitcoin Cash. (This is already the case.)
  2. All the wallet software providers should make it easy to use m/44'/145'/0', because it's the correct, standard-conforming thing to do.
  3. Whenever a non-default derivation path is in use, the user interface should make this clear to the user. (Coinomi is the only one that already does this.)
  4. Wallet software should not use unnecessarily creative, nonstandard terminology. If new terminology is needed let's all agree to it, so users don't encounter different terms in different places for the same thing.

Also relevant:

avibrazil commented 6 years ago

I’m the reporter of #6803. I support this feature request to improve clarity and avoid confusion in clients.

matiu commented 6 years ago

I agree. We need to make this change. New wallets will use m/44'/145'/0', and we will scan both paths m/44'/145'/0' and m/44'/0'/0' when a wallet is imported. Do you agree this is ok?

avibrazil commented 6 years ago

I agree. As I said on #6803, prefork-imported wallets should use m/44'/0'/... and new wallets should use m/44'/145'/...

avibrazil commented 6 years ago

Same for Bitcoin Gold and m/44'/156'/...

Using Coinomi I have found I actually have Bitcoin Gold funds from the pre-fork era (2017-11) that has a $278 value per BTG on Bittrex.com. Its like finding forgotten money in your pocket !!

fortran77 commented 6 years ago

From @matiu :

New wallets will use m/44'/145'/0', and we will scan both paths m/44'/145'/0' and m/44'/0'/0' when a wallet is imported. Do you agree this is ok?

This sounds fine to me.

I think that no matter what you do, there is no ideal solution. Let me list the benefits and costs of various approaches.

The forked Bitcoin.com wallet software by default always creates identical BTC and BCH m/44'/0'/0' wallets that use the same seed words. Benefits:

  1. The user effortlessly gets access to forked BCH, if he restores using his pre-existing seed words.
  2. The user also gets access to future BCH that might be accidentally sent to m/44'/0'/0' BCH addresses.

Cost:

Loss of privacy. Any time the user provides a receiving address to somebody, that other person knows a receiving address in both wallets. (Which is why BIP44 gives each coin its own address space.)

The Coinomi software requires the user to explicitly add a BCH wallet with the nonstandard m/44'/0'/0' path. This has a different set of benefits and costs. Benefits:

  1. The user gets access to forked BCH, if he follows published instructions and restores using his pre-existing seed words (or adds an m/44'/0'/0' BCH wallet to his existing Coinomi app).
  2. The user also gets access to future BCH that might be accidentally sent to m/44'/0'/0' BCH addresses.
  3. Since the user will (following published instructions) have two BCH wallets, one for m/44'/0'/0' and another for m/44'/145'/0', he can (if he makes the effort) keep BTC receiving addresses separate from BCH addresses. So there is no loss of privacy.

Cost:

User inconvenience. The user has to make an explicit effort to add the m/44'/0'/0' BCH wallet, and make an explicit effort to use a receiving address in the m/44'/145'/0' wallet, and in general have to cope with the confusion of having two different BCH wallets. (Albeit, the m/44'/0'/0' wallet is automatically labeled to be distinguishable from the m/44'/145'/0' wallet.)

So now let me list the benefits and costs of the proposal "New wallets will use m/44'/145'/0', and we will scan both paths m/44'/145'/0' and m/44'/0'/0' when a wallet is imported." Benefits:

  1. The user effortlessly gets access to forked BCH, if he restores using his pre-existing seed words.
  2. Since the user has an m/44'/145'/0' BCH wallet, his BTC receiving addresses are automatically kept distinct from BCH addresses. So there is no loss of privacy.

Cost:

Possible loss of funds. (But the risk is low.) Any future funds arriving in m/44'/0'/0' BCH addresses will be invisible to the user, as that chain is (presumably) checked only when the wallet is initially created or imported.

All three approaches above seem quite viable to me, given that there is no perfect solution. As I technical person I prefer Coinomi's explicit approach.

For all the rest of us, the other two approaches are better and less likely to confuse users. The equation here is either loss of privacy (forked Bitcoin.com wallet) or loss of funds (@matiu's proposal). The risk of loss of funds should be low -- presumably nobody will be sending new BCH to old BTC addresses.

lubokkanev commented 5 years ago

Seems this has already been resolved?