[bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Daniel Weigl]

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



    

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]

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:

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

[-- Attachment #2: Type: text/html, Size: 3058 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]

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:

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

[-- Attachment #2: Type: text/html, Size: 1816 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1575 bytes --]

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:

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

[-- Attachment #2: Type: text/html, Size: 2260 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Andreas Schildbach]

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jonas Schnelli]

[-- Attachment #1.1: Type: text/plain, Size: 1197 bytes --]

Hi

> 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.

--
</jonas>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jochen Hoenicke]

Am 13.05.2016 um 15:16 schrieb Daniel Weigl via bitcoin-dev:
> 
> 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.


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

> 	-) 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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jochen Hoenicke]

Am 14.05.2016 um 10:16 schrieb Jonas Schnelli via bitcoin-dev:
> 
> 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.

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

[-- Attachment #1.1: Type: text/plain, Size: 335 bytes --]

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.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

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.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Jonas Schnelli]

[-- Attachment #1.1: Type: text/plain, Size: 2011 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On Sat, May 14, 2016 at 7:08 AM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

> 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/>

[-- Attachment #2: Type: text/html, Size: 2734 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Kenneth Heutmaker]

> * 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.

> * 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.

> * 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.

> * 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.

> 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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Thomas Voegtlin]

[-- Attachment #1.1: Type: text/plain, Size: 683 bytes --]



Le 14/05/2016 18:14, Jonas Schnelli via bitcoin-dev a écrit :
> 
> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Pavol Rusnak]

[-- Attachment #1.1: Type: text/plain, Size: 919 bytes --]

On 14/05/16 18:14, Jonas Schnelli wrote:
> 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.

> * 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.

> * 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.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
SatoshiLabs.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Daniel Weigl]

Hi,

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

Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...

[Aaron Voisine]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

On Sun, May 15, 2016 at 5:08 AM, Daniel Weigl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> > 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.


>  -) 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/>

[-- Attachment #2: Type: text/html, Size: 2624 bytes --]