summaryrefslogtreecommitdiff
path: root/00/da8f6cd14fea71b3b2938db81ad3d892af803c
blob: 93cd62402db77ce9b8b5f43e61b300429bbbe52c (plain)
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
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
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 F38337A8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 May 2018 00:10:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com
	[209.85.215.41])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55E88F8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  4 May 2018 00:10:06 +0000 (UTC)
Received: by mail-lf0-f41.google.com with SMTP id w8-v6so28519589lfe.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 03 May 2018 17:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=clarkmoody-com.20150623.gappssmtp.com; s=20150623;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc; bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=;
	b=eYAyMAH+GQJgo0UBwgRCvyN1B07MKzcgrwVw22yALSkBPiGHrUkgyH4ipUOgmkPAD7
	Ix2HazPIowwMzVNEyaTJjscWceTZOhBUe6t2+/ATfGJT7DA5MiHHzl2k7g3zGXB7/egW
	J/zBLbV5ZQx7HHEmffJ1RL9wjhqlu58W1KggwVu4PakoxjmN3lEkwY6uKOmevppxyaqZ
	D1uA8rjCnglx2KGFb7TITVRXY/EsBtXTtlXeUUegGlW6izcyhvglMJgYa2t3RDltLSUO
	bUc7YemtaXNfg4V1pGBdYbvLN2vzT26i94o/vr9o6PsMM5cKVOJ9bHh/Y3YThffbZRxQ
	+emw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:cc;
	bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=;
	b=LUIqCqNrA+dwZ4lWMBdYg3i0vvJBbMUjiLhRJh3YPVfRYxn5NTaVVwlebl//Rg2g5Z
	0gszaxv09rpzqRBjgnUy/L9CMBjmFqAB6E8U1VY8K91HvVQdv6YX7yN16KiFX2ziynyY
	LiCDYue8HnSmhb0ZM0qBxMfR+58zLWPMkpSMBYwqn/jjMSEQYCfcJ6dX4QDufLiQFjrw
	TnNEMpcbBh9y71/jX8mFwmxePHM0v/YKpdpc2iOd6NeF3tQuUOxEK4THGJldbTftUgwf
	YY/w4coKPXZGWDftKzqM8cVmIj5gGSOdSNg7uShe0M20PlULoHUycZMx/VK1cB5FGG1Z
	AUgQ==
X-Gm-Message-State: ALQs6tAj5SRuUEzmyxGMqYrEWXdT8QQgqkWNJTjjEJ5r+xQQdbEeSBzS
	fTp53Kymb3FMph258dyXbWsGcs7YeiYIqrAyjtQ=
X-Google-Smtp-Source: AB8JxZrAQASlLkHUBlfFJInEQv09IbAQVK7+VQs8jRXlphf8Fzcd0eliZ+m+Ccpwmsb6aME+vZquYF876g8aB8SlJF0=
X-Received: by 2002:a2e:2c01:: with SMTP id
	s1-v6mr3466626ljs.120.1525392604551; 
	Thu, 03 May 2018 17:10:04 -0700 (PDT)
MIME-Version: 1.0
References: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com>
	<CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com>
	<HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com>
In-Reply-To: <HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com>
From: Clark Moody <clark@clarkmoody.com>
Date: Fri, 04 May 2018 00:09:38 +0000
Message-ID: <CAHGSxGsyQ7=NdE6x7c+cfJY=3tVCNpTuy971xvqFT7SQ70PrAQ@mail.gmail.com>
To: Paul Brown <paul@345.systems>
Content-Type: multipart/alternative; boundary="000000000000565e2e056b562464"
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: Fri, 04 May 2018 11:37:07 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Fri, 04 May 2018 00:10:08 -0000

--000000000000565e2e056b562464
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Paul,

The current BIP-49 / 84 use the purpose field of the derivation path to spe=
cify
the address format.

=E2=80=8BI think sticking with the one-BIP-one-format method works. Otherwi=
se, you
would need to modify this proposed BIP each time a new format comes along.
In that case, existing wallets that claim BIP-XXXX compliance will be
incomplete.


-Clark

On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown <paul@345.systems> wrote:

> Hi
>
> I realised after I sent my previous response that the encoding was wrong
> and that my smiley face at the end of the BIP number comment got turned
> into a ? and the tongue in cheek context was lost :-(
>
> Anyway, back onto subject.  I've been thinking some more on the SLIP-0032
> adoption in this proposal and specifically the address format to use when
> generating addresses.
>
> My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however=
,
> I wonder whether there is some merit in extending the derivation path wit=
h
> an additional level below coin type to represent the address format, with
> the value determined by the context of the coin type value in the
> derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin ty=
pe
> is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc).
> A separate spec similar to SLIP-0044 could be created that defines the li=
st
> of address formats and the derivation path values.
>
> When importing root master seeds or distributing the xpub's for each
> cosigner to each party the discovery process in the proposal would need
> extending to try each address format in turn to determine whether there i=
s
> a 'hit' when checking balances.  It does mean that the import process is
> slower however the additional flexibility of supporting multiple address
> formats possibly outweighs this.  I'm just thinking that having a rule to
> follow during discovery, particularly where non-Bitcoin coins are
> concerned, is more explicit than leaving it open to the wallet implemente=
r
> to figure out (for altcoins, what address format to use?).
>
> It also means that future address formats are supported as they are simpl=
y
> added to the new spec list for the coin type (can be done by anyone,
> similar to the way SLIP-0044 works now) - it doesn't require a new BIP to
> support.  For example, if address format was a derivation level in BIP44,
> would BIP49 and BIP84 be needed?
>
> I'm somewhat musing out loud here, but I like the idea of being able to
> mostly self-discover as much as possible and reducing or eliminating the
> need for proprietary metadata attached to the wallet.
>
> Cheers
> Paul
>
> From: clarkmoody@gmail.com <clarkmoody@gmail.com> On Behalf Of Clark Mood=
y
> Sent: 25 April 2018 15:36
> To: Paul Brown <paul@345.systems>; Bitcoin Protocol Discussion <
> bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in on=
e
> BIP32 derivation path (new BIP)
>
> Thanks for the proposal, Paul.
>
> > - What address format is expected when discovering balances and creatin=
g
> 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 t=
he
> 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 th=
e
> address space for the various formats. SLIP-0032 solves this bootstrappin=
g
> 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 <mailto:
> 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/ms=
g05188.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
> mailto:bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--000000000000565e2e056b562464
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:#000000">Paul,</div><div class=3D"gmail_def=
ault" style=3D"font-family:tahoma,sans-serif;font-size:small;color:#000000"=
><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se=
rif;font-size:small;color:#000000">The current BIP-49 / 84 use the purpose =
field of the derivation path to=C2=A0<span style=3D"color:rgb(0,0,0);font-f=
amily:tahoma,sans-serif;font-size:small;font-style:normal;font-variant-liga=
tures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal=
;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo=
rd-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:init=
ial;text-decoration-color:initial;float:none;display:inline">specify the ad=
dress format</span>.</div><div class=3D"gmail_extra"><br clear=3D"all"><div=
><div class=3D"m_8866112210612112144gmail_signature" data-smartmail=3D"gmai=
l_signature"><div><div class=3D"gmail_default" style=3D"font-family:tahoma,=
sans-serif;font-size:small;color:rgb(0,0,0)">=E2=80=8BI think sticking with=
 the one-BIP-one-format method works. Otherwise, you would need to modify t=
his proposed BIP each time a new format comes along. In that case, existing=
 wallets that claim BIP-XXXX compliance will be incomplete.</div><br></div>=
<div><br></div><div>-Clark</div><div></div></div></div>
<br><div class=3D"gmail_quote">On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown =
<span dir=3D"ltr">&lt;<a href=3D"mailto:paul@345.systems" target=3D"_blank"=
>paul@345.systems</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">H=
i<br>
<br>
I realised after I sent my previous response that the encoding was wrong an=
d that my smiley face at the end of the BIP number comment got turned into =
a ? and the tongue in cheek context was lost :-(<br>
<br>
Anyway, back onto subject.=C2=A0 I&#39;ve been thinking some more on the SL=
IP-0032 adoption in this proposal and specifically the address format to us=
e when generating addresses.<br>
<br>
My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however, =
I wonder whether there is some merit in extending the derivation path with =
an additional level below coin type to represent the address format, with t=
he value determined by the context of the coin type value in the derivation=
 path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type is Bitcoi=
n, 0x00 for Ethereum account format if coin type is Ether, etc).=C2=A0 A se=
parate spec similar to SLIP-0044 could be created that defines the list of =
address formats and the derivation path values.<br>
<br>
When importing root master seeds or distributing the xpub&#39;s for each co=
signer to each party the discovery process in the proposal would need exten=
ding to try each address format in turn to determine whether there is a &#3=
9;hit&#39; when checking balances.=C2=A0 It does mean that the import proce=
ss is slower however the additional flexibility of supporting multiple addr=
ess formats possibly outweighs this.=C2=A0 I&#39;m just thinking that havin=
g a rule to follow during discovery, particularly where non-Bitcoin coins a=
re concerned, is more explicit than leaving it open to the wallet implement=
er to figure out (for altcoins, what address format to use?).<br>
<br>
It also means that future address formats are supported as they are simply =
added to the new spec list for the coin type (can be done by anyone, simila=
r to the way SLIP-0044 works now) - it doesn&#39;t require a new BIP to sup=
port.=C2=A0 For example, if address format was a derivation level in BIP44,=
 would BIP49 and BIP84 be needed?<br>
<br>
I&#39;m somewhat musing out loud here, but I like the idea of being able to=
 mostly self-discover as much as possible and reducing or eliminating the n=
eed for proprietary metadata attached to the wallet.<br>
<br>
Cheers<br>
<span>Paul<br>
<br>
From: <a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank">clarkmoody@=
gmail.com</a> &lt;<a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank"=
>clarkmoody@gmail.com</a>&gt; On Behalf Of Clark Moody<br>
Sent: 25 April 2018 15:36<br>
To: Paul Brown &lt;paul@345.systems&gt;; Bitcoin Protocol Discussion &lt;<a=
 href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one =
BIP32 derivation path (new BIP)<br>
<br>
</span><span>Thanks for the proposal, Paul.<br>
<br>
&gt;=C2=A0- What address format is expected when discovering balances and c=
reating transactions?<br>
<br>
Your solution does not solve your first bullet point, since the xpub encodi=
ng looks no different than any other xpub (BIP 44, 45, 49, etc). At the lea=
st, you should propose new version bytes to change the &quot;xpub&quot; in =
the encoding to some other string.<br>
<br>
Alternatively, I would suggest that you use the xpub serialization format d=
escribed in SLIP-0032 (<a href=3D"https://github.com/satoshilabs/slips/blob=
/master/slip-0032.md" rel=3D"noreferrer" target=3D"_blank">https://github.c=
om/satoshilabs/slips/blob/master/slip-0032.md</a>). It includes the derivat=
ion path within the xpub itself and uses Bech32 for encoding.<br>
<br>
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 whic=
h BIP number the xpub conforms.<br>
<br>
Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)=
<br>
<br>
Thanks<br>
<br>
<br>
<br>
<br>
-Clark<br>
<br>
</span><span>On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev &l=
t;mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
Hi<br>
=C2=A0<br>
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.=
=C2=A0 It combines BIP44 and BIP45 and adds in a self-describing structure =
in the derivation path for multiple multi-sig combinations within the singl=
e wallet along with an extended public key export file format for public ke=
y distribution between parties.=C2=A0 I can particularly see this being use=
ful for multiple Lightning Network 2of2 accounts for different payment chan=
nels.<br>
=C2=A0<br>
The BIP can be found here: <a href=3D"https://github.com/gluexchange/bip/bl=
ob/master/bip-0046.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://=
github.com/gluexchange/bip/blob/master/bip-0046.mediawiki</a><br>
=C2=A0<br>
I appreciate that this might be re-hashing old ground as BIP44 in particula=
r has been widely adopted, however, BIP44 does leave itself open to a lot o=
f interpretation from a wallet portability perspective such as:<br>
=C2=A0<br>
- What address format is expected when discovering balances and creating tr=
ansactions?<br>
- Does the master seed represent a single-sig or multi-sig wallet?<br>
- If multi-sig, how many cosigners and what are their extended public keys =
(so that the wallet can generate the correctly formatted redeem script with=
 public keys in the right order)?<br>
- If multi-sig, how do you prevent collisions on the same address index (in=
 a wallet that is occasionally connected)?<br>
=C2=A0<br>
BIP45 solves the collision that occurs when the individual parties in a mul=
ti-sig group each give out a new address from a wallet, where the wallet ha=
sn=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).=C2=A0 It uses a cosigner index in the derivation path so that each =
party has their own path to their addresses.=C2=A0 However, BIP45 drops the=
 multi-coin support that BIP44 has.<br>
=C2=A0<br>
This is a useful discussion on the problems of a collision and the merits o=
f separating cosigners in the derivation path: <a href=3D"https://www.mail-=
archive.com/bitcoin-development@lists.sourceforge.net/msg05188.html" rel=3D=
"noreferrer" target=3D"_blank">https://www.mail-archive.com/bitcoin-develop=
ment@lists.sourceforge.net/msg05188.html</a><br>
=C2=A0<br>
For the purposes of the BIP text (and the example paths used to generate ke=
ys) I=E2=80=99ve temporarily assigned it the number 46.=C2=A0 It looks like=
 that is available and seemed somewhat appropriate given that it builds on =
the good work of BIP44 and BIP45.<br>
=C2=A0<br>
Paul Brown<br>
=C2=A0<br>
=C2=A0<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
</span>mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ=
et=3D"_blank">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>
<br>
</blockquote></div><br></div></div>

--000000000000565e2e056b562464--