1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Return-Path: <voisine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 54A8C7D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2016 16:03:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f182.google.com (mail-yw0-f182.google.com
[209.85.161.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3FE7E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2016 16:03:11 +0000 (UTC)
Received: by mail-yw0-f182.google.com with SMTP id g133so106852601ywb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 13 May 2016 09:03:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc; bh=Mlh4umI4fkTir1WA9aTa/QJlVgXWMP8++WoQ0bdT4Ec=;
b=PTI4dLw3n+SRjJU7Bfnixm5nJ65FhDmVPom36o/tMlHbJ1ovw0vuvsbnw1NlwtKw8K
gAd53JjQYOdJHrVclMGPk3yqqw1v/QoEOFKHL1JzPvgUZlO5X5bvRv5jlB6FTbjk3Glt
/eucHtrgE5mw8i5RpVjL3uek1o1NdQjhC8FYPwXI3yTwQpkfLQQKYnNwe6A8Z629bN7L
RFxwYbYXjK1eVD+RDsKZpvEz3cU9lSmX3AVXHnjLjsNRehx7MhEo+gAPSQpvPviLl32j
xA+DVB0Fxhqb61dz9W6asomsHVTE/4wIEKhEIKhPeFKrYecVZlmTWb5g+MScnQlxzKfx
9+bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc;
bh=Mlh4umI4fkTir1WA9aTa/QJlVgXWMP8++WoQ0bdT4Ec=;
b=ciTMfd/gBfHSXoAnMP7jRydy8SfSc2OlEqAHMnm9H4Kiu41EpHUjEBMdhD8+vz6WtA
1DXR2N9wnvNfNMN01euWXfYuIbl6ZMya5xhT1UV39sgIcyrYx2AViHbVDRxfNytUeyvY
MVNgMMGW8qq65TpPlK+qPOdAjyfgAqoYQiojjuGtNESqJhT3OXGbVrRVbAaeAGt1cSEQ
Ss4vlCtkjEhyqp9HGUjOwP7Y3w0Xi9oPTGzre/WhYqy3w6mjupp8+mOkQ0r8asheBXIZ
olX0GZUjYG8JpvHOUv77U/2z8es9WfLBcetf+5T9saxVeVT4xLyNXgg2UAt4qOLLjUD2
81hA==
X-Gm-Message-State: AOPr4FUyHJ43lR4o6CeM9uXVxvBF++dv/arWWTBGe46LVQ8mEiKUO3EM9wCkx/M1r3vMtjc/ipR62PPqFmXGIw==
MIME-Version: 1.0
X-Received: by 10.129.154.77 with SMTP id r74mr8676394ywg.91.1463155391229;
Fri, 13 May 2016 09:03:11 -0700 (PDT)
Received: by 10.13.233.2 with HTTP; Fri, 13 May 2016 09:03:11 -0700 (PDT)
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
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 13 May 2016 16:05:59 +0000
Subject: Re: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 13 May 2016 16:03:13 -0000
--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 "0". We were thinking of of having 4 chains below the=
"account" 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"><<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.o=
rg</a>></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>
> 2) Define a new derivation path, parallel to Bip44, but a different=C2=
=A0 'purpose' (eg. <BipNumber-of-this-BIP>' instead of 44=
'). Let the user choose which account he want to add ("Normal acco=
unt", "Witness account").<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'd like to implement this way in=
<br>
myTREZOR.<br>
<span class=3D""><br>
>=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>
> 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 "stick" 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--
|
