Bip44 extension for P2SH/P2WSH/...
20 messages, 13 to 15 May 2016. Started by Daniel Weigl.
Pavol Rusnak (6), Aaron Voisine (5), Daniel Weigl (2), Jonas Schnelli (2), Jochen Hoenicke (2), Andreas Schildbach, Kenneth Heutmaker, Thomas Voegtlin
Hello List,
With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses. I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
In my opinion there are two(?) different options:
1) Stay with the current Bip44 account, give the user for each public key the option to show it as a P2PKH-Address or a P2SH address and also scan the blockchain for both representation of each public key. +) This has the advantage, that the user does not need to decide or have to understand that he needs to migrate to a new account type -) The downside is that the wallet has to scan/look for ever twice as much addresses. In the future when we have a P2WPKH, it will be three times as much. -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").
m / purpose' / coin_type' / account' / change / address_index
+) Wallet needs only to take care of 1 address per public key +) If you use more than one wallet on the same xPub/xPriv it will work or fail completely. You will notice it immediately that there is something wrong -) User has to understand that (s)he needs to migrate to a new account to get the benefits of SegWit +) Thus, its easier to make a staged roll-out, only user actively deciding to use SegWit will get it and we can catch bugs earlier.
3) other ideas?
My personal favourite is pt2.
Has any Bip44 compliant wallet already done any integration at this point?
Thx, Daniel/Mycelium
On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
Quoted text (1 line)
> 2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").We had quite a long discussion in our team some time ago and we agreed on that option #2 is much better and we'd like to implement this way in myTREZOR.
Quoted text (1 line)
> +) Wallet needs only to take care of 1 address per public key
True, if this BIP only supports P2WPKH.
P2WSH should probably be handled by another account type and another BIP, anyway.
Quoted text (1 line)
> Has any Bip44 compliant wallet already done any integration at this point?
We have something in the pipeline, but no visible results yet.
We use the default BIP32 wallet layout, mentioned in BIP43 as purpose "0". We were thinking of of having 4 chains below the "account" level, the original 0 and 1 for receive and change addresses, and then 0x40000000 and 0x40000001 for P2WPKH-in-P2SH versions of receive and change addresses.
I like the idea of specifying the type of address as a bit field flag. 0x80000000 is already used to specify hardened derivation, so 0x40000000 would be the next available to specify witness addresses. This is compatible with existing accounts and wallet layouts.
As Daniel mentioned, the downside is that trying to recover on non-segwit software will miss segwit receives, however it does avoid the problem of having to check multiple address types for each key.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 8:00 AM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (31 lines)
> On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:
> > 2) Define a new derivation path, parallel to Bip44, but a different
> 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user
> choose which account he want to add ("Normal account", "Witness account").
>
> We had quite a long discussion in our team some time ago and we agreed
> on that option #2 is much better and we'd like to implement this way in
> myTREZOR.
>
> > +) Wallet needs only to take care of 1 address per public key
>
> True, if this BIP only supports P2WPKH.
>
> P2WSH should probably be handled by another account type and another
> BIP, anyway.
>
> > Has any Bip44 compliant wallet already done any integration at this
> point?
>
> We have something in the pipeline, but no visible results yet.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> SatoshiLabs.com
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation•org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>On 13/05/16 18:03, Aaron Voisine wrote:
Quoted text (4 lines)
> I like the idea of specifying the type of address as a bit field flag. > 0x80000000 is already used to specify hardened derivation, so 0x40000000 > would be the next available to specify witness addresses. This is > compatible with existing accounts and wallet layouts.
I think this is over-optimization. What is the advantage of
m/0'/0x40000000 instead of m/whatever'/0 ?
But this is off-topic anyway, as we are discussing multiple-accounts per wallet layout here, not one-account-per-wallet design.
This scheme is independent of the number of accounts. It works with BIP44 as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of overloading the account index to indicate the type of address, you use the chain index, which is already being used to indicate what the specific address chain is to be used for, i.e. receive vs change addresses.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 9:11 AM, Pavol Rusnak <stick@satoshilabs•com> wrote:
Quoted text (19 lines)
> On 13/05/16 18:03, Aaron Voisine wrote: > > I like the idea of specifying the type of address as a bit field flag. > > 0x80000000 is already used to specify hardened derivation, so 0x40000000 > > would be the next available to specify witness addresses. This is > > compatible with existing accounts and wallet layouts. > > I think this is over-optimization. What is the advantage of > > m/0'/0x40000000 instead of m/whatever'/0 ? > > But this is off-topic anyway, as we are discussing multiple-accounts per > wallet layout here, not one-account-per-wallet design. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > SatoshiLabs.com >
On 13/05/16 18:59, Aaron Voisine wrote:
Quoted text (5 lines)
> This scheme is independent of the number of accounts. It works with BIP44 > as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of > overloading the account index to indicate the type of address, you use the > chain index, which is already being used to indicate what the specific > address chain is to be used for, i.e. receive vs change addresses.
I see the advantage here. But there is a major problem here.
We came up with BIP44 so a wallet can claim it is BIP44 compatible and you can be 100% sure that you can migrate accounts from one wallet implementation to another. This was not previously possible when a wallet claimed it is BIP32 compatible.
Now we have a similar problem. When there is a BIP44 wallet, does it mean it supports segwit or not? For this reason I would like to see another BIPXX for segwit, so a wallet can claim it is BIP44, BIP44+BIPXX or BIPXX compatible and you'll know what other wallets are compatible with it.
That's a valid concern, but I don't see the conflict here. In order to recover funds from a wallet conforming to BIPXX, you must have wallet software that handles BIPXX. Simply making BIPXX backwards compatible with previously created BIP44 or BIP43 purpose 0 wallets doesn't change this at all.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com>
On Fri, May 13, 2016 at 10:57 AM, Pavol Rusnak <stick@satoshilabs•com> wrote:
Quoted text (27 lines)
> On 13/05/16 18:59, Aaron Voisine wrote: > > This scheme is independent of the number of accounts. It works with BIP44 > > as well as BIP43 purpose 0, or any other BIP43 purpose/layout. Instead of > > overloading the account index to indicate the type of address, you use > the > > chain index, which is already being used to indicate what the specific > > address chain is to be used for, i.e. receive vs change addresses. > > I see the advantage here. But there is a major problem here. > > We came up with BIP44 so a wallet can claim it is BIP44 compatible and > you can be 100% sure that you can migrate accounts from one wallet > implementation to another. This was not previously possible when a > wallet claimed it is BIP32 compatible. > > Now we have a similar problem. When there is a BIP44 wallet, does it > mean it supports segwit or not? For this reason I would like to see > another BIPXX for segwit, so a wallet can claim it is BIP44, BIP44+BIPXX > or BIPXX compatible and you'll know what other wallets are compatible > with it. > > -- > Best Regards / S pozdravom, > > Pavol "stick" Rusnak > SatoshiLabs.com >
The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs define balance retrieval never changes. This is to make sure you always see the same balance on "same BIP" wallets (and same seed of course).
So if you want to add paths, it has to be a new BIP.
On 05/13/2016 03:16 PM, Daniel Weigl via bitcoin-dev wrote:
Quoted text (30 lines)
> Hello List,
>
> With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses.
> I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first.
>
> In my opinion there are two(?) different options:
>
> 1) Stay with the current Bip44 account, give the user for each public key the option to show it as a P2PKH-Address or a P2SH address and also scan the blockchain for both representation of each public key.
> +) This has the advantage, that the user does not need to decide or have to understand that he needs to migrate to a new account type
> -) The downside is that the wallet has to scan/look for ever twice as much addresses. In the future when we have a P2WPKH, it will be three times as much.
> -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
>
> 2) Define a new derivation path, parallel to Bip44, but a different 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the user choose which account he want to add ("Normal account", "Witness account").
>
> m / purpose' / coin_type' / account' / change / address_index
>
> +) Wallet needs only to take care of 1 address per public key
> +) If you use more than one wallet on the same xPub/xPriv it will work or fail completely. You will notice it immediately that there is something wrong
> -) User has to understand that (s)he needs to migrate to a new account to get the benefits of SegWit
> +) Thus, its easier to make a staged roll-out, only user actively deciding to use SegWit will get it and we can catch bugs earlier.
>
> 3) other ideas?
>
> My personal favourite is pt2.
>
> Has any Bip44 compliant wallet already done any integration at this point?
>
> Thx,
> Daniel/Mycelium
>Hi
Quoted text (5 lines)
> That's a valid concern, but I don't see the conflict here. In order to > recover funds from a wallet conforming to BIPXX, you must have wallet > software that handles BIPXX. Simply making BIPXX backwards compatible > with previously created BIP44 or BIP43 purpose 0 wallets doesn't change > this at all.
Maybe I'm going a bit offtopic. Sorry for that.
Importing a bip32 wallet (bip44 or not) is still an expert job IMO. Also importing can lead to bad security practice (especially without a sweep).
Users will send around xpriv or import an seed over a compromised computer to a cold storage, etc.
I don't think users want to import private keys. They probably want to import the transaction history and send all funds covered by that seed to a new wallet.
I often though that task is better covered by a little GUI tool or cli-app/script: -> Accept different bip32 schematics (bip32 native, bip44, etc.) -> Accept different bip39 (like) implementation -> Create large lookup windows -> Create a sweep transaction to a new address/wallet and sign/broadcast it. -> Export transaction history (CSV)
But maybe I'm over-complicating things.
Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev:
Quoted text (4 lines)
> > With SegWit approaching it would make sense to define a common derivation scheme how BIP44 compatible wallets will handle P2(W)SH (and later on P2WPKH) receiving addresses. > I was thinking about starting a BIP for it, but I wanted to get some feedback from other wallets devs first. >
The discussion so far shows that starting a new BIP is a very good idea. Otherwise everyone would do it slightly different.
With P2(W)SH you mean P2WPKH embedded in P2SH, right? P2WSH is completely different and used for example for multisig.
Quoted text (1 line)
> In my opinion there are two(?) different options:
To summarize, option 1 means one account that supports both non-segwit and segwit addresses. With option 2 you have one p2pkh-only account and one segwit-only account, which are completely separated.
I personally would vote for option 1. Scanning twice the addresses can be avoided with Aaron's trick. The second disadvantage remains:
Quoted text (1 line)
> -) If you have the same xPub/xPriv key in different wallets, you need to be sure both take care for the different address types
A non-segwit wallet would ignore all segwit outputs, which means that the balance it shows is smaller (and it doesn't show transactions that spend from previous segwit outputs). I don't see that this can lead to losing money except maybe when sweeping the account with a p2pkh-only wallet and then throwing the xprv away.
Of course, you can also do option 2 and let it appear to the user as if it was only one account, but what is the advantage over option 1 in that case? Also you need two xpubs to watch this joined account.
Jochen
Am 14.05.2016 um 10:16 schrieb Jonas Schnelli via bitcoin-dev:
Quoted text (4 lines)
> > Importing a bip32 wallet (bip44 or not) is still an expert job IMO. > Also importing can lead to bad security practice (especially without a > sweep).
One important use case is importing xpubs for watch-only accounts. This is necessary for hardware wallets and there are other valid use cases for this.
Quoted text (8 lines)
> > Users will send around xpriv or import an seed over a compromised > computer to a cold storage, etc. > > I don't think users want to import private keys. > They probably want to import the transaction history and send all funds > covered by that seed to a new wallet. >
Yes, in general it is not a good idea to import private keys and many wallets don't even have an option to give out the xprv (except indirectly via the backup mechanism). But even when sweeping a bip-44+segwit wallet you need to know where the segwit addresses are.
Jochen
On 14/05/16 10:16, Jonas Schnelli via bitcoin-dev wrote:
Quoted text (1 line)
> Importing a bip32 wallet (bip44 or not) is still an expert job IMO.
That's simply not true. All reasonable wallets (reasonable = user oriented) now use BIP39 mnemonic for doing exactly this.
On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote:
Quoted text (3 lines)
> The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs > define balance retrieval never changes. This is to make sure you always > see the same balance on "same BIP" wallets (and same seed of course).
This! Thanks Andreas for formulating my thought that I was not able to articulate earlier.
Quoted text (5 lines)
> On 14/05/16 10:16, Jonas Schnelli via bitcoin-dev wrote: >> Importing a bip32 wallet (bip44 or not) is still an expert job IMO. > > That's simply not true. All reasonable wallets (reasonable = user > oriented) now use BIP39 mnemonic for doing exactly this.
AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs android wallet [1] and Electrum [2] and Breadwallet [3].
But I think forming a BIP39 mnemonic into a extended master private key is not the problem here.
The problems I see: * What if the "old" wallet has used more then 1000 addresses? I guess some wallets do not even create a lookup window up to 1000 addresses. There is a high chance of loosing funds when doing sweep (move all funds to a new wallet) operation.
* I guess most or maybe all wallets will keep all keys (the "lookup-window" keys) in the wallet database which could affect performance [4]
* I guess most wallets do not offer "moving the funds to a new seed" [5] which results in not solving the problem of a "lost" or "compromised" wallet and implies wrong security to the enduser.
* If I import a bip39 mnemonic into a hardware wallet (assume Trezor or Keepkey) I have to type in the words into my computer which bypasses some of the security my hardware wallet provides me (MITM seed attack). Together with the point above this reduces the security of a wallet (in particular cold storage significant).
Please correct me if I'm wrong.
I just wanted to point out that importing a wallet is a tricky step especially cross-wallet imports (I think cross wallet imports is an experts job without further improvements).
[1] https://github.com/bitcoin-wallet/bitcoin-wallet/issues/245 [2] http://docs.electrum.org/en/latest/seedphrase.html [3] https://github.com/voisine/breadwallet/issues/360 [4] https://github.com/bitcoin-wallet/bitcoin-wallet/issues/158 [5] https://github.com/voisine/breadwallet/blob/master/BreadWallet/BRRestoreViewController.m#L225
</jonas>
On Sat, May 14, 2016 at 7:08 AM, Pavol Rusnak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (8 lines)
> On 14/05/16 09:00, Andreas Schildbach via bitcoin-dev wrote: > > The whole idea of BIP43 (which BIP44 bases on) is that how these BIPs > > define balance retrieval never changes. This is to make sure you always > > see the same balance on "same BIP" wallets (and same seed of course). > > This! Thanks Andreas for formulating my thought that I was not able to > articulate earlier. >
Indeed, this would still be the case when using a new BIPXX to define adding segwit chains to what were previously BIP43/44 wallets. In this case retrieval of a BIP44 wallet remains exactly the same as it did before. A BIP44 wallet can still be recovered with any BIP44 compatible wallet software. After you upgrade an existing BIP44 wallet to a BIPXX wallet, now it is no longer a BIP44 wallet. It is now a BIPXX wallet, and can only be recovered using BIPXX compatible wallet software.
If you are concerned about making a new BIP that fits in the BIP43 framework, i.e. a new purpose number, there's no reason this can't also be done. You could create a new purpose number YY. Wallets that follow BIPYY look just like BIPXX, except that they may only contain segwit address chains, no standard P2PKH address chains.
On Sat, May 14, 2016 at 9:14 AM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
> AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs > android wallet [1] and Electrum [2] and Breadwallet [3].
Breadwallet is BIP39, with the BIP43 purpose 0 derivation path, and I believe Schlindbachs is as well. Electrum has their own format. I don't know if it also supports sweeping other mnemonics and wallet layouts.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com/>
Quoted text (4 lines)
> * What if the "old" wallet has used more then 1000 addresses? I guess > some wallets do not even create a lookup window up to 1000 addresses. > There is a high chance of loosing funds when doing sweep (move all funds > to a new wallet) operation.
If that is the case, the wallet is not following the standard. The wallet hierarchy standards like BIP44 specify how to walk an address chain. They all specify that you should keep going until you don’t find any more used keys within the lookup window. If a wallet leaves gaps that are too big, that is also not compliant.
In any case, if the sweeping wallet understands how the “old” wallet uses the hierarchy, it can be safely swept without a potential loss of funds.
Quoted text (3 lines)
> * I guess most or maybe all wallets will keep all keys (the > "lookup-window" keys) in the wallet database which could affect > performance [4]
Yes, wallets with more addresses take more time to process.
Quoted text (3 lines)
> * I guess most wallets do not offer "moving the funds to a new seed" [5] > which results in not solving the problem of a "lost" or "compromised" > wallet and implies wrong security to the enduser.
Some wallets do and for those that don’t, implementing it is straight forward if it already implements BIP32. It’s just a matter of knowing how the old wallet uses the hierarchy and prioritizing the work.
Quoted text (5 lines)
> * If I import a bip39 mnemonic into a hardware wallet (assume Trezor or > Keepkey) I have to type in the words into my computer which bypasses > some of the security my hardware wallet provides me (MITM seed attack). > Together with the point above this reduces the security of a wallet (in > particular cold storage significant).
Both TREZOR and KeepKey have developed strategies to prevent MITM attacks during seed recovery. TREZOR asks for the words in a random order and in some cases, adds ’noise’ words. KeepKey uses a rotating substitution cipher.
Quoted text (3 lines)
> I just wanted to point out that importing a wallet is a tricky step > especially cross-wallet imports (I think cross wallet imports is an > experts job without further improvements).
I don’t think it is as hard as you think. If a wallet uses BIP32 HD, all of the hard code is already implemented. It is just a matter of stringing the correct sequence of steps together.
Also, if the new hierarchy is under a separate purpose code as specified in BIP43, there is no need to create new seed. The BIP44 hierarchy and the new hierarchy can be extended from the same seed.
— Ken Heutmaker, KeepKey
Le 14/05/2016 18:14, Jonas Schnelli via bitcoin-dev a écrit :
Quoted text (3 lines)
> > AFAIK: Bip39 import (cross-wallet) is not supported by [...] Electrum [2] . >
That is correct. There are several reasons why I decided not to use BIP39 in Electrum. One of them was that BIP39 seed phrases do not include a version number. A version number is needed in order to maintain backward compatibility, everytime you change the address derivation.
Electrum will allocate a new version number for seed phrases that should be derived to segwit addresses.
I guess BIP39 designers will have to change the semantics of their checksum bits, in order to encode a version number for segwit.
On 14/05/16 18:14, Jonas Schnelli wrote:
Quoted text (2 lines)
> AFAIK: Bip39 import (cross-wallet) is not supported by Schildbachs > android wallet [1] and Electrum [2] and Breadwallet [3].
They are not BIP44 compatible wallets. This thread is about BIP44.
Quoted text (1 line)
> * What if the "old" wallet has used more then 1000 addresses? I guess
They are not following the spec and are thus not BIP44 compatible.
Quoted text (5 lines)
> * If I import a bip39 mnemonic into a hardware wallet (assume Trezor or > Keepkey) I have to type in the words into my computer which bypasses > some of the security my hardware wallet provides me (MITM seed attack). > Together with the point above this reduces the security of a wallet (in > particular cold storage significant).
You should send all your coins to the new seed anyway, but I agree this might be tricky for non-power users.
Hi,
Quoted text (2 lines)
> 0x40000000 would be the next available to specify witness addresses. > This is compatible with existing accounts and wallet layouts.
my main concern here is that -) every Bip<this-bip>-compatible wallet in the future will have to implement all (then probably) legacy derivation and tx schemes. -) it does not fail in a deterministic way, if I import a seed or xPriv/xPub across different capable wallets. It is more visible if one account has [no funds/does not show up] at all after an import than if something shows up but you need to make sure that the balance is what you might expect.
Daniel/Mycelium
On 2016-05-13 18:03, Aaron Voisine wrote:
Quoted text (53 lines)
> We use the default BIP32 wallet layout, mentioned in BIP43 as purpose > "0". We were thinking of of having 4 chains below the "account" > level, the original 0 and 1 for receive and change addresses, and > then 0x40000000 and 0x40000001 for P2WPKH-in-P2SH versions of receive > and change addresses. > > I like the idea of specifying the type of address as a bit field > flag. 0x80000000 is already used to specify hardened derivation, so > 0x40000000 would be the next available to specify witness addresses. > This is compatible with existing accounts and wallet layouts. > > As Daniel mentioned, the downside is that trying to recover on > non-segwit software will miss segwit receives, however it does avoid > the problem of having to check multiple address types for each key. > > Aaron Voisine co-founder and CEO breadwallet > <http://breadwallet.com> > > On Fri, May 13, 2016 at 8:00 AM, Pavol Rusnak via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote: >> 2) Define a new derivation path, parallel to Bip44, but a different >> 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44'). Let the >> user choose which account he want to add ("Normal account", >> "Witness account"). > > We had quite a long discussion in our team some time ago and we > agreed on that option #2 is much better and we'd like to implement > this way in myTREZOR. > >> +) Wallet needs only to take care of 1 address per public key > > True, if this BIP only supports P2WPKH. > > P2WSH should probably be handled by another account type and another > BIP, anyway. > >> Has any Bip44 compliant wallet already done any integration at this >> point? > > We have something in the pipeline, but no visible results yet. > > -- Best Regards / S pozdravom, > > Pavol "stick" Rusnak SatoshiLabs.com > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (8 lines)
> > > 0x40000000 would be the next available to specify witness addresses. > > This is compatible with existing accounts and wallet layouts. > > my main concern here is that > -) every Bip<this-bip>-compatible wallet in the future will have to > implement all (then probably) legacy derivation and tx schemes. >
I can see the advantage of a segwit only scheme, but we will need to support old derivations anyway for many decades if not indefinitely. People are using it to store value for the long term.
Quoted text (6 lines)
> -) it does not fail in a deterministic way, if I import a seed or > xPriv/xPub across different capable wallets. > It is more visible if one account has [no funds/does not show up] > at all after an import than if something shows up but you need to make sure > that the balance is what you might expect. >
This is certainly a downside. It has to be weighed against the benefit of being able to upgrade existing wallets in place. Asking users to create a new wallet, and replace their recovery phrase backups is an even bigger problem in my estimation.
What do you think of doing both? A new BIP43 purpose number for segwit only wallets, but that also specifies 0x40000000/1 for the change/receive index so that the scheme is compatible with other schemes for upgrade existing wallets in place? There will certainly be wallet developers who decide to upgrade in place, but we can standardized both how to indicate segwit chains, independent of segwit only schemes or upgrade schemes, and still have the advantages of a new segwit only BIP43 purpose number.
Aaron Voisine co-founder and CEO breadwallet <http://breadwallet.com/>