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
|
Return-Path: <emcquinn8@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 19FE5C0001
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 15:54:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by fraxinus.osuosl.org (Postfix) with ESMTP id 0EDA685E51
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 15:54:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id a1SUMIZ0OFsk
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 15:54:10 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com
[209.85.210.44])
by fraxinus.osuosl.org (Postfix) with ESMTPS id D800B85DF6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 15:54:09 +0000 (UTC)
Received: by mail-ot1-f44.google.com with SMTP id v16so7976540ote.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Feb 2021 07:54:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=IJUsWguqrroZ5FkHhpgJNe6gvSGXI0ixtupT2IGCiJo=;
b=U//8jBRHvhH/Ez06SrK/oScg8UsJxo8WuNa2YN/PZDQX+KlvWB8GwuBzaIvM126R+B
TUvzJ+NVijTYZ+lWRWRiMUT9H0hss7swkyh7F0O28Bc5FEoqra8FBJIZomSLnIaicBII
LpzGOgssoq9/KR/Rfe+xmZ7vggUaTTLSXps8lez7cJvN/+0bIyjb//EhVgzzvTZdikKb
Tc0pcAWpQmQVk2g36O+ewSvHIdz1DqjFbQ0BQxKT4fuJZs3w/3M7xvU55buT7pVPuzEI
aPyWYnqPwgeLBfm3coJV3s8DPWqt8EmerAQZVqZsU2F5Tgv8EkVmKPGh4TfapaYOvyvg
KoMw==
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;
bh=IJUsWguqrroZ5FkHhpgJNe6gvSGXI0ixtupT2IGCiJo=;
b=VrPng8iDAXyaQKuIL7+s5ODPkSopnOJsZZKNFQ390hYhUs1LGbBxlcxysKDHjU8B3M
vwb6qfWt9rBh4eWyCHHckrGYaqGxTuy0TFKAO6unZ+9yXV8arSLmhXA/zoD4Uu1C1Dhm
hHmIm7GwCancu8ax/GpyKEWR1qcE6SQuQUQwRv+4sApopkJDHD2egYjyPh0lzjT6lit1
5ks1ybyaV+6Rj7IMKmDcvoZnV96sfl4KVTiAQ5C1YLaIll7R6W4YPzavmUm4HqCVnBxK
NXKiRdo1i9Z7sjoVitcV+kEbdk+6JRliKvvqhCy69MGQarigIufPVAyAK1geBdWhnirz
Upsw==
X-Gm-Message-State: AOAM531opqfR7tvRb6obcG56+JwbZDiXB8DSe/raMasCpns/KcjN9fnr
3VimhatEKZkegEE4ZTEnYqlHyDVvu7vhhKy42fU=
X-Google-Smtp-Source: ABdhPJwGXHmbFB+eR+Ez67T4/XbXHYCY35M/4NIM93Jyxq5f8oBSbKnrADNZiYUt4Fb7OrZC6rQCDoxgjsig9vPpFYs=
X-Received: by 2002:a9d:6c4c:: with SMTP id g12mr10933583otq.53.1613836449036;
Sat, 20 Feb 2021 07:54:09 -0800 (PST)
MIME-Version: 1.0
References: <63e9654c-44b8-740b-79a7-bb58f7bd198c@electrum.org>
<b60a7654-0252-90af-7ec1-b3de3ed74ae7@degreesofzero.com>
<CACvH2ek=bM=0vH-skjhr2VnaF47U3eht5P3ukJ7CUnB3V8ZGQQ@mail.gmail.com>
In-Reply-To: <CACvH2ek=bM=0vH-skjhr2VnaF47U3eht5P3ukJ7CUnB3V8ZGQQ@mail.gmail.com>
From: Eoin McQuinn <emcquinn8@gmail.com>
Date: Sat, 20 Feb 2021 15:53:57 +0000
Message-ID: <CAPeP9hkhJPu_wEa0_qudiUQNb8Lkb7L6Ue1aTVLGrPD0mF6yFw@mail.gmail.com>
To: Andrew Kozlik <andrew.kozlik@satoshilabs.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000453cbc05bbc69485"
X-Mailman-Approved-At: Sun, 21 Feb 2021 13:26:05 +0000
Subject: Re: [bitcoin-dev] BIP70 is dead. What now?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Sat, 20 Feb 2021 15:54:12 -0000
--000000000000453cbc05bbc69485
Content-Type: text/plain; charset="UTF-8"
What is a 'pull request'?
On Fri, Feb 19, 2021 at 1:49 PM Andrew Kozlik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Thomas,
>
> I am working on an experimental implementation [1] of a new payment
> request format in Trezor T. In some respects it's similar to BIP-70. The
> main differences are:
>
> 1. There is no reliance on X.509, since that seems to have been the main
> reason for BIP-70's downfall. The signature is mandatory, since for us the
> main feature is protection against a man-in-the-middle attack. So in this
> sense it's more similar to BOLT11.
>
> 2. It can be used to solve a similar problem with coin exchange. When you
> are sending BTC to a trusted exchange service and expecting another
> cryptocurrency in return, say LTC, you want to be sure that you not only
> have the correct BTC address, but also that the exchange service has your
> correct LTC address.
>
> 3. It uses an optional nonce for replay protection.
>
> The two interesting parts in [1] are probably the `TxAckPaymentRequest`
> protobuf message [2] and the signature verification [3]. The protobuf
> message is only for communication between Trezor and the host software
> running on the user's computer. It's not intended for interchange between
> wallets. We haven't defined the interchange format yet. I intend to create
> a SLIP documenting all this.
>
> Andrew
>
> [1] https://github.com/trezor/trezor-firmware/compare/andrewkozlik/payreq2
> [2]
> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messages-bitcoin.proto#L403-L427
> [3]
> https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.py
>
> On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi, Thomas,
>>
>> I developed a URL signing scheme for use with LNURL as a method for
>> authorizing payments on behalf of offline devices /applications. It's
>> not specifically off-chain or on-chain related, but could be repurposed.
>> The gist of the scheme is as follows:
>>
>> Before any signing is done:
>>
>> 0) Generate an API key (ID/reference, secret, encoding) to be shared
>> between a server and an offline device or application.
>>
>> To generate a signature:
>>
>> 1) Generate a random nonce (unique per API key)
>>
>> 2) Build a query string with the `id`, `nonce`, `tag`, "Server
>> parameters" (see [Subprotocols](#subprotocols) above), and any custom
>> parameters. The `id` parameter should be equal to the API key's ID.
>> Example:
>> `id=b6cb8e81e3&nonce=d585674cf991dbbab42b&tag=withdrawRequest&minWithdrawable=5000&maxWithdrawable=7000&defaultDescription=example&custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE`.
>>
>> Note that both the keys and values for query parameters should be URL
>> encoded. The following characters should be __unescaped__: `A-Z a-z 0-9
>> - _ . ! ~ * ' ( )`. See
>> [encodeURIComponent](
>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description)
>>
>> for more details.
>>
>> 3) Sort the query parameters by key (alphabetically). This is referred
>> to as the "payload". Example:
>>
>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest`
>>
>> 4) Sign the payload (the sorted query string) using the API key secret.
>> Signatures are generated using HMAC-SHA256, where the API key secret is
>> the key.
>>
>> 5) Append the signature to the payload as follows:
>>
>> `custom1=CUSTOM1_PARAM_VALUE&custom2=CUSTOM2_PARAM_VALUE&defaultDescription=example&id=b6cb8e81e3&maxWithdrawable=7000&minWithdrawable=5000&nonce=d585674cf991dbbab42b&tag=withdrawRequest&signature=HMAC_SHA256_SIGNATURE`.
>>
>> You can find more details here:
>>
>> https://github.com/chill117/lnurl-node#how-to-implement-url-signing-scheme
>>
>>
>> I would change a few things with this scheme to fit better with the
>> use-case you describe. For example:
>>
>> * Remove the "tag" and LNURL-specific parameters
>>
>> * Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key
>> signing instead. The lnurl-auth subprotocol has an interesting approach
>> to protecting user privacy while allowing verification of signatures.
>> See for more details on that:
>>
>> https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md
>>
>>
>> - chill
>>
>>
>> On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:
>> > I never liked BIP70. It was too complex, had too many features, and when
>> > people discuss it, they do not even agree on what the main feature was.
>> >
>> > Nevertheless, there is ONE feature of BIP70 that I find useful: the fact
>> > that payment requests were signed. I am making this post to discuss
>> this.
>> >
>> > When I send bitcoins to an exchange, I would like to receive a signed
>> > request. I want to have a proof that the exchange asked me to send coins
>> > to that address, in case it has been hijacked by some intern working
>> > there. If that feature was implemented by an exchange, it would guide my
>> > decision to use that exchange over its competitors.
>> >
>> > I do not think that a single exchange ever implemented that, but I guess
>> > this is because BIP70 is a terrible standard. LN payment requests are
>> > signed, do not require SSL, do not require interactivity, and therefore
>> > exchanges use them. Can't we achieve the same for on-chain payments? Is
>> > anyone working on that?
>> >
>> > I would be more than happy to remove BIP70 support from Electrum, if
>> > there was another standard for signed requests.
>> >
>> > Thomas
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
eoin.substack.com
--000000000000453cbc05bbc69485
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What is a 'pull request'?</div><br><div class=3D"g=
mail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 19, 2021 at 1=
:49 PM Andrew Kozlik via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div>Hi Thomas,</div><div><br></div><div>I am working on an experimental =
implementation [1] of a new payment request format in Trezor T. In some res=
pects it's similar to BIP-70. The main differences are:</div><div><br><=
/div><div>1. There is no reliance on X.509, since that seems to have been t=
he main reason for BIP-70's downfall. The signature is mandatory, since=
for us the main feature is protection against a man-in-the-middle attack. =
So in this sense it's more similar to BOLT11.</div><div><br></div><div>=
2. It can be used to solve a similar problem with coin exchange. When you a=
re sending BTC to a trusted exchange service and expecting another cryptocu=
rrency in return, say LTC, you want to be sure that you not only have the c=
orrect BTC address, but also that the exchange service has your correct LTC=
address.</div><div><br></div><div>3. It uses an optional nonce for replay =
protection.</div><br>The two interesting parts in [1] are probably the `TxA=
ckPaymentRequest` protobuf message [2] and the signature verification [3]. =
The protobuf message is only for communication between Trezor and the host =
software running on the user's computer. It's not intended for inte=
rchange between wallets. We haven't defined the interchange format yet.=
I intend to create a SLIP documenting all this.<br><div><br></div><div>And=
rew <br></div><div><br></div>[1] <a href=3D"https://github.com/trezor/trezo=
r-firmware/compare/andrewkozlik/payreq2" target=3D"_blank">https://github.c=
om/trezor/trezor-firmware/compare/andrewkozlik/payreq2</a><br>[2] <a href=
=3D"https://github.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/com=
mon/protob/messages-bitcoin.proto#L403-L427" target=3D"_blank">https://gith=
ub.com/trezor/trezor-firmware/blob/andrewkozlik/payreq2/common/protob/messa=
ges-bitcoin.proto#L403-L427</a><br>[3] <a href=3D"https://github.com/trezor=
/trezor-firmware/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/pa=
yment_request.py" target=3D"_blank">https://github.com/trezor/trezor-firmwa=
re/blob/andrewkozlik/payreq2/core/src/apps/bitcoin/sign_tx/payment_request.=
py</a><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Fri, Feb 19, 2021 at 1:43 PM Charles Hill via bitcoin-dev <=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Hi, Thomas,<br>
<br>
I developed a URL signing scheme for use with LNURL as a method for <br>
authorizing payments on behalf of offline devices /applications. It's <=
br>
not specifically off-chain or on-chain related, but could be repurposed. <b=
r>
The gist of the scheme is as follows:<br>
<br>
Before any signing is done:<br>
<br>
0) Generate an API key (ID/reference, secret, encoding) to be shared <br>
between a server and an offline device or application.<br>
<br>
To generate a signature:<br>
<br>
1) Generate a random nonce (unique per API key)<br>
<br>
2) Build a query string with the `id`, `nonce`, `tag`, "Server <br>
parameters" (see [Subprotocols](#subprotocols) above), and any custom =
<br>
parameters. The `id` parameter should be equal to the API key's ID. <br=
>
Example: <br>
`id=3Db6cb8e81e3&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRequest=
&minWithdrawable=3D5000&maxWithdrawable=3D7000&defaultDescripti=
on=3Dexample&custom1=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_=
VALUE`. <br>
Note that both the keys and values for query parameters should be URL <br>
encoded. The following characters should be __unescaped__: `A-Z a-z 0-9 <br=
>
- _ . ! ~ * ' ( )`. See <br>
[encodeURIComponent](<a href=3D"https://developer.mozilla.org/en-US/docs/We=
b/JavaScript/Reference/Global_Objects/encodeURIComponent#description" rel=
=3D"noreferrer" target=3D"_blank">https://developer.mozilla.org/en-US/docs/=
Web/JavaScript/Reference/Global_Objects/encodeURIComponent#description</a>)=
<br>
for more details.<br>
<br>
3) Sort the query parameters by key (alphabetically). This is referred <br>
to as the "payload". Example: <br>
`custom1=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_VALUE&defaul=
tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m=
inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRe=
quest`<br>
<br>
4) Sign the payload (the sorted query string) using the API key secret. <br=
>
Signatures are generated using HMAC-SHA256, where the API key secret is <br=
>
the key.<br>
<br>
5) Append the signature to the payload as follows: <br>
`custom1=3DCUSTOM1_PARAM_VALUE&custom2=3DCUSTOM2_PARAM_VALUE&defaul=
tDescription=3Dexample&id=3Db6cb8e81e3&maxWithdrawable=3D7000&m=
inWithdrawable=3D5000&nonce=3Dd585674cf991dbbab42b&tag=3DwithdrawRe=
quest&signature=3DHMAC_SHA256_SIGNATURE`.<br>
<br>
You can find more details here:<br>
<br>
<a href=3D"https://github.com/chill117/lnurl-node#how-to-implement-url-sign=
ing-scheme" rel=3D"noreferrer" target=3D"_blank">https://github.com/chill11=
7/lnurl-node#how-to-implement-url-signing-scheme</a><br>
<br>
<br>
I would change a few things with this scheme to fit better with the <br>
use-case you describe. For example:<br>
<br>
* Remove the "tag" and LNURL-specific parameters<br>
<br>
* Instead of HMAC-SHA256 with a shared secret, it could use pub/priv key <b=
r>
signing instead. The lnurl-auth subprotocol has an interesting approach <br=
>
to protecting user privacy while allowing verification of signatures. <br>
See for more details on that:<br>
<br>
<a href=3D"https://github.com/fiatjaf/lnurl-rfc/blob/master/lnurl-auth.md" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/fiatjaf/lnurl-rfc/b=
lob/master/lnurl-auth.md</a><br>
<br>
<br>
- chill<br>
<br>
<br>
On 2/19/21 10:14 AM, Thomas Voegtlin via bitcoin-dev wrote:<br>
> I never liked BIP70. It was too complex, had too many features, and wh=
en<br>
> people discuss it, they do not even agree on what the main feature was=
.<br>
><br>
> Nevertheless, there is ONE feature of BIP70 that I find useful: the fa=
ct<br>
> that payment requests were signed. I am making this post to discuss th=
is.<br>
><br>
> When I send bitcoins to an exchange, I would like to receive a signed<=
br>
> request. I want to have a proof that the exchange asked me to send coi=
ns<br>
> to that address, in case it has been hijacked by some intern working<b=
r>
> there. If that feature was implemented by an exchange, it would guide =
my<br>
> decision to use that exchange over its competitors.<br>
><br>
> I do not think that a single exchange ever implemented that, but I gue=
ss<br>
> this is because BIP70 is a terrible standard. LN payment requests are<=
br>
> signed, do not require SSL, do not require interactivity, and therefor=
e<br>
> exchanges use them. Can't we achieve the same for on-chain payment=
s? Is<br>
> anyone working on that?<br>
><br>
> I would be more than happy to remove BIP70 support from Electrum, if<b=
r>
> there was another standard for signed requests.<br>
><br>
> Thomas<br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=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>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=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>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature"><div dir=3D"ltr"><a href=3D"http://eoin.substack=
.com" target=3D"_blank">eoin.substack.com</a></div></div>
--000000000000453cbc05bbc69485--
|