MIME-Version: 1.0
In-Reply-To: <5735EC17.5040901@satoshilabs.com>
References: <5735D3A4.7090608@mycelium.com> <5735EC17.5040901@satoshilabs.com>
Date: Fri, 13 May 2016 09:03:11 -0700
Message-ID: <CACq0ZD4BvvCryYmO-J9Rof-ogQJ1wNLgmUEU596nuTH=-U8Hag@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
To: Pavol Rusnak <stick@satoshilabs.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0b8ce4587f710532bb6944
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Precedence: list

--94eb2c0b8ce4587f710532bb6944
Content-Type: text/plain; charset=UTF-8

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
>

--94eb2c0b8ce4587f710532bb6944
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We use the default BIP32 wallet layout, mentioned in BIP43=
 as purpose &quot;0&quot;. We were thinking of of having 4 chains below the=
 &quot;account&quot; level, the original 0 and 1 for receive and change add=
resses, and then 0x40000000 and 0x40000001 for P2WPKH-in-P2SH versions of r=
eceive and change addresses.<div><br></div><div>I like the idea of specifyi=
ng the type of address as a bit field flag. 0x80000000 is already used to s=
pecify hardened derivation, so 0x40000000 would be the next available to sp=
ecify witness addresses. This is compatible with existing accounts and wall=
et layouts.</div><div><br></div><div>As Daniel mentioned, the downside is t=
hat trying to recover on non-segwit software will miss segwit receives, how=
ever it does avoid the problem of having to check multiple address types fo=
r each key.</div><div class=3D"gmail_extra"><br><div><div class=3D"gmail_si=
gnature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=
Aaron Voisine</div><div>co-founder and CEO<br><a href=3D"http://breadwallet=
.com" target=3D"_blank">breadwallet</a></div></div></div></div></div></div>=
</div></div>
<br><div class=3D"gmail_quote">On Fri, May 13, 2016 at 8:00 AM, Pavol Rusna=
k via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>On 13/05/16 15:16, Daniel Weigl via bitcoin-dev wrote:<br>
&gt; 2) Define a new derivation path, parallel to Bip44, but a different=C2=
=A0 &#39;purpose&#39; (eg. &lt;BipNumber-of-this-BIP&gt;&#39; instead of 44=
&#39;). Let the user choose which account he want to add (&quot;Normal acco=
unt&quot;, &quot;Witness account&quot;).<br>
<br>
</span>We had quite a long discussion in our team some time ago and we agre=
ed<br>
on that option #2 is much better and we&#39;d like to implement this way in=
<br>
myTREZOR.<br>
<span class=3D""><br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0+) Wallet needs only to take care of 1 addre=
ss per public key<br>
<br>
</span>True, if this BIP only supports P2WPKH.<br>
<br>
P2WSH should probably be handled by another account type and another<br>
BIP, anyway.<br>
<span class=3D""><br>
&gt; Has any Bip44 compliant wallet already done any integration at this po=
int?<br>
<br>
</span>We have something in the pipeline, but no visible results yet.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Best Regards / S pozdravom,<br>
<br>
Pavol &quot;stick&quot; Rusnak<br>
SatoshiLabs.com<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div></div>

--94eb2c0b8ce4587f710532bb6944--