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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
|
Return-Path: <clarkmoody@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A4F5888D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Apr 2018 14:36:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com
[209.85.215.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A5FB42D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Apr 2018 14:36:30 +0000 (UTC)
Received: by mail-lf0-f44.google.com with SMTP id u21-v6so24215005lfu.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 25 Apr 2018 07:36:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=;
b=qlMoHjJ0bTdnLaG9XwUYfC70O5CLpMC4z9c/jhakMAWjbd1nreEBnJXQ72wncpA1EH
QXihsjZb3qSFpwp/t5mJ2XmiMatXAWlx/4D+FCNiWWv/jMLnWARopNmHT5I0yfLr/6eA
/yjU94rfTfFF475iEafpWykL+07bPe744KUlRigSnxr7WDXgJ/j9oHm1Xb2YO/FzM8wP
hpraxhseu0moNfCd1oShhxPNpIsaNEkLmYG7wnH4ZVgz8wq+fqNbeYQMIaQZX2uh8rWc
x2xN7YAiykdcIDvqS+SEELwJFhu50Frfw0rBSET3c0Wg5JyR3/FqN98SDXh5LbBDBZiz
jCMQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=clarkmoody-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=;
b=OQywjZCV4mxxX6wzt4MqW7H5E0iRP/sQeOlN558QiWKWap4Nedk4UovkXgISnn4nEl
G9kjsbO7jRz3FGYt6W31Ka5e9+C6JWR8eCSyT6GUOVZhmdKHdC378a0HcGdzJqtTYCLM
dD8nucN/LmlayM0c4YGyJkSrARRndc+afOU8PsuRybzrJVcIOc3ySM44oKp0MFQ9s1ie
O8jDKdho5vDlmW/28RUwDfCNXyX1l4+DJJ+zfLWcDu/K+L++fLCwPLUwMrAc708r2ygV
DjLCkKu0/JyN3pHKPVFqNyEhU6Oc3ZslcAlkalNf5J0/KXTtJPDi9Dqdgj62HDNzRx2I
DR3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to;
bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=;
b=Cgwb0hO+qoZCTTsmoSjyupy1FDZb2fNwjOs90LNSTjDP4huASXllMPYCeY3sjGBKH1
t1mqzUYASGHp+W0GyVe7PGkWc6RTQ+e7A6Cx512BxgMXUJDFSnmsNa3WWkK8nQfFvFtO
4req7GP1ujvPN1mCkZODojeMkUJf4CpI97sslz7uG3F7PmV9z+7/LfZ8VUfqQ1E23Hwt
kAy97la44EuK+PUFBStg/A6U/Mzjfk/X8otsDdeJFlpnu25xZree3Ouphf1WoHYqZuur
cQAXkoa4T9Ep8yGsg0yuUibthKvt6fcPkd9NGOovrX/rLgvAfU63YuNu8co0AHkmAINh
+k9g==
X-Gm-Message-State: ALQs6tAMjLjRq3E1sjREnAfD5EwOSK9pS1QyfpITW8rQ/uXoTOBn6qJL
K50vfVAhV7baXDhXLxVtmeYVxUlUHrX1m3f+wU5SOOQZ
X-Google-Smtp-Source: AB8JxZoEgxxlE9TSfc39GGCzXu4Tw94cuyLVVuGUUKbcqYXkHsADUcbH/gx6PafvzrnSeuZRrm6uOOdI9l/BfuG35ig=
X-Received: by 2002:a19:8f82:: with SMTP id
s2-v6mr15133094lfk.55.1524666988624;
Wed, 25 Apr 2018 07:36:28 -0700 (PDT)
MIME-Version: 1.0
Sender: clarkmoody@gmail.com
Received: by 10.46.101.8 with HTTP; Wed, 25 Apr 2018 07:35:57 -0700 (PDT)
In-Reply-To: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>
References: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>
From: Clark Moody <clark@clarkmoody.com>
Date: Wed, 25 Apr 2018 09:35:57 -0500
X-Google-Sender-Auth: BoQ2-9dNTwS2yW4DpANo6e7uCPk
Message-ID: <CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com>
To: Paul Brown <paul@345.systems>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000041ff05056aad327d"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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: Wed, 25 Apr 2018 14:40:33 +0000
Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one
BIP32 derivation path (new BIP)
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: Wed, 25 Apr 2018 14:36:31 -0000
--00000000000041ff05056aad327d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thanks for the proposal, Paul.
*> - What address format is expected when discovering balances and creating
transactions?*
Your solution does not solve your first bullet point, since the xpub
encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At
the least, you should propose new version bytes to change the "xpub" in the
encoding to some other string.
Alternatively, I would suggest that you use the xpub serialization format
described in SLIP-0032 (
https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It includes
the derivation path within the xpub itself and uses Bech32 for encoding.
Given a normal xpub with no additional information, a wallet must scan the
address space for the various formats. SLIP-0032 solves this bootstrapping
problem and avoids the UX nightmare of users being required to know to
which BIP number the xpub conforms.
Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)
Thanks
-Clark
On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi
>
>
>
> I have written a new BIP describing a BIP32 derivation path that supports
> a single or multi-signature and multi-coin wallet from a single master
> seed. It combines BIP44 and BIP45 and adds in a self-describing structur=
e
> in the derivation path for multiple multi-sig combinations within the
> single wallet along with an extended public key export file format for
> public key distribution between parties. I can particularly see this bei=
ng
> useful for multiple Lightning Network 2of2 accounts for different payment
> channels.
>
>
>
> The BIP can be found here: https://github.com/gluexchange/bip/blob/master=
/
> bip-0046.mediawiki
>
>
>
> I appreciate that this might be re-hashing old ground as BIP44 in
> particular has been widely adopted, however, BIP44 does leave itself open
> to a lot of interpretation from a wallet portability perspective such as:
>
>
>
> - What address format is expected when discovering balances and creating
> transactions?
>
> - Does the master seed represent a single-sig or multi-sig wallet?
>
> - If multi-sig, how many cosigners and what are their extended public key=
s
> (so that the wallet can generate the correctly formatted redeem script wi=
th
> public keys in the right order)?
>
> - If multi-sig, how do you prevent collisions on the same address index
> (in a wallet that is occasionally connected)?
>
>
>
> BIP45 solves the collision that occurs when the individual parties in a
> multi-sig group each give out a new address from a wallet, where the wall=
et
> hasn=E2=80=99t been able to sync to mark the address as =E2=80=98used=E2=
=80=99 (this could happen
> if they gave out addresses independently at the same time). It uses a
> cosigner index in the derivation path so that each party has their own pa=
th
> to their addresses. However, BIP45 drops the multi-coin support that BIP=
44
> has.
>
>
>
> This is a useful discussion on the problems of a collision and the merits
> of separating cosigners in the derivation path:
> https://www.mail-archive.com/bitcoin-development@lists.
> sourceforge.net/msg05188.html
>
>
>
> For the purposes of the BIP text (and the example paths used to generate
> keys) I=E2=80=99ve temporarily assigned it the number 46. It looks like =
that is
> available and seemed somewhat appropriate given that it builds on the goo=
d
> work of BIP44 and BIP45.
>
>
>
> Paul Brown
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--00000000000041ff05056aad327d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s=
ans-serif;font-size:small;color:rgb(0,0,0)">Thanks for the proposal, Paul.<=
/div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><i>>=
;=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font=
-size:12.8px">- What address format is expected when discovering balances a=
nd creating transactions?</span></i><br></div><div class=3D"gmail_default" =
style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><i=
><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:=
12.8px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:4=
00;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:no=
ne;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);te=
xt-decoration-style:initial;text-decoration-color:initial;float:none;displa=
y:inline"><br></span></i></div><div class=3D"gmail_default" style=3D""><spa=
n style=3D"font-size:12.8px"><span style=3D"color:rgb(0,0,0);font-family:ta=
homa,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:no=
rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al=
ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci=
ng:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text=
-decoration-color:initial;float:none;display:inline">Your solution does not=
solve your first bullet point, s</span>ince the xpub encoding looks no dif=
ferent than any other xpub (BIP 44, 45, 49, etc). At the least, you should =
propose new version bytes to change the "xpub" in the encoding to=
some other string.</span></div><div class=3D"gmail_default" style=3D"font-=
family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)">Alternatively, I would suggest that you use the xpub s=
erialization format described in SLIP-0032 (<a href=3D"https://github.com/s=
atoshilabs/slips/blob/master/slip-0032.md">https://github.com/satoshilabs/s=
lips/blob/master/slip-0032.md</a>). It includes the derivation path within =
the xpub itself and uses Bech32 for encoding.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0=
)"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-=
serif;font-size:small;color:rgb(0,0,0)">Given a normal xpub with no additio=
nal information, a wallet must scan the address space for the various forma=
ts. SLIP-0032 solves this bootstrapping problem and avoids the UX nightmare=
of users being required to know to which BIP number the xpub conforms.</di=
v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-=
size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">Also, @=
luke-jr will give you a hard time to self-assigning a BIP number ;-)</div><=
div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks</div>=
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail=
_signature" data-smartmail=3D"gmail_signature"><div><br></div><div><br></di=
v><div>-Clark</div><div></div></div></div>
<br><div class=3D"gmail_quote">On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown =
via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72">
<div class=3D"m_8836520283562771257WordSection1">
<p class=3D"MsoNormal">Hi<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">I have written a new BIP describing a BIP32 derivati=
on path that supports a single or multi-signature and multi-coin wallet fro=
m a single master seed.=C2=A0 It combines BIP44 and BIP45 and adds in a sel=
f-describing structure in the derivation
path for multiple multi-sig combinations within the single wallet along wi=
th an extended public key export file format for public key distribution be=
tween parties.=C2=A0 I can particularly see this being useful for multiple =
Lightning Network 2of2 accounts for different
payment channels.<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">The BIP can be found here: <a href=3D"https://github=
.com/gluexchange/bip/blob/master/bip-0046.mediawiki" target=3D"_blank">
https://github.com/<wbr>gluexchange/bip/blob/master/<wbr>bip-0046.mediawiki=
</a><u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">I appreciate that this might be re-hashing old groun=
d as BIP44 in particular has been widely adopted, however, BIP44 does leave=
itself open to a lot of interpretation from a wallet portability perspecti=
ve such as:<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">- What address format is expected when discovering b=
alances and creating transactions?<u></u><u></u></p>
<p class=3D"MsoNormal">- Does the master seed represent a single-sig or mul=
ti-sig wallet?<u></u><u></u></p>
<p class=3D"MsoNormal">- If multi-sig, how many cosigners and what are thei=
r extended public keys (so that the wallet can generate the correctly forma=
tted redeem script with public keys in the right order)?<u></u><u></u></p>
<p class=3D"MsoNormal">- If multi-sig, how do you prevent collisions on the=
same address index (in a wallet that is occasionally connected)?<u></u><u>=
</u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">BIP45 solves the collision that occurs when the indi=
vidual parties in a multi-sig group each give out a new address from a wall=
et, where the wallet hasn=E2=80=99t been able to sync to mark the address a=
s =E2=80=98used=E2=80=99 (this could happen if they gave out
addresses independently at the same time).=C2=A0 It uses a cosigner index =
in the derivation path so that each party has their own path to their addre=
sses.=C2=A0 However, BIP45 drops the multi-coin support that BIP44 has.<u><=
/u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">This is a useful discussion on the problems of a col=
lision and the merits of separating cosigners in the derivation path:
<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor=
ge.net/msg05188.html" target=3D"_blank">
https://www.mail-archive.com/<wbr>bitcoin-development@lists.<wbr>sourceforg=
e.net/msg05188.html</a><u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">For the purposes of the BIP text (and the example pa=
ths used to generate keys) I=E2=80=99ve temporarily assigned it the number =
46.=C2=A0 It looks like that is available and seemed somewhat appropriate g=
iven that it builds on the good work of BIP44 and
BIP45.<span class=3D"HOEnZb"><font color=3D"#888888"><u></u><u></u></font>=
</span></p><span class=3D"HOEnZb"><font color=3D"#888888">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal">Paul Brown<u></u><u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</font></span></div>
</div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--00000000000041ff05056aad327d--
|