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
|
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 10EE4B43
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 23:46:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com
[209.85.220.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2370D229
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 Jan 2017 23:46:02 +0000 (UTC)
Received: by mail-qk0-f178.google.com with SMTP id u25so380647644qki.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 03 Jan 2017 15:46:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=5XqL7df8249TSerxo+1y5rAKcbVCvszPFUICoG1ihQs=;
b=MNWbQiMRdyYFzQR+klB1jhsHj067MYjf1jyF7PTv7AQ5ZkZg/V2nHzuSwvTc5kr6YQ
ODb54mP+16EDWOTKcfy5ik7Md/jpkN/LDJs/JFfScPSHE66siXzfmg1elERrmmm+bhnM
hVsbmnPF9KNSGrPhdsTK1E9zgSoVCbo8Wf6zu+ThI70rTuRZ4ytaEvqANOmNeluoaXKL
s4xcxq/oXyI8TDs+pwWoz7s7TZ+Tk4HwKpGdZO03KCeM13oaxWEntFzASLS1sgv2qI/W
TH6sKItxR/n8Nym6joH4heKMTud9MYCpmTVOby8DPGeLVWkvLy56+Hi3upm4Er+nEDyC
Duvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=5XqL7df8249TSerxo+1y5rAKcbVCvszPFUICoG1ihQs=;
b=QWxt2aycJayOP0tXrIHOicmcyY5mIQSqkJRakEJMl2FqIbdIRGqU7ripwOBjNXw7Rx
LcBcthmps7MRGUMD7FWyvmmlV1MNOnYtzSn3LoAFdPE6CYEstli8+UFb5Sta4jB9H5T/
y27FU7isLa+Zu5+GRcA8HCzh7sdMVm/UxiFrAHH1kz3ruX0SBOnby5LhZbpNCpduXEGH
f1u0U5VG4zVIulywndajzCckp7RDoIiCP2KIpIZZuSWBV0eDDhDdwnMENAbfAvCeOJoS
nMBOjXYmy3ba+lL5EkbaexO0DtgRNHBAj1ee6xTi0TjUuYRhOERYfLpBQWO0r3qDFhcI
KKUw==
X-Gm-Message-State: AIkVDXIDPyeOCHPXp9gmM+fsrHzfFuhIaTRB7DXCuvbsAs0UmHD2jgXal/fuVDjZ58OAY/5wcHEtKu97Sk1dug==
X-Received: by 10.55.112.65 with SMTP id l62mr72499043qkc.76.1483487161300;
Tue, 03 Jan 2017 15:46:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.164.98 with HTTP; Tue, 3 Jan 2017 15:46:00 -0800 (PST)
In-Reply-To: <CAKEeUhiQiUA_E6JF22foV11-WnGZH+kEzfUhROm=gvVN1qMr4A@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
<CAKEeUhiQiUA_E6JF22foV11-WnGZH+kEzfUhROm=gvVN1qMr4A@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
Date: Tue, 3 Jan 2017 15:46:00 -0800
Message-ID: <CACq0ZD5WV7ORmEJgGSquyRzndH_XP9FrLbwSNKQC5Zuh08NVDw@mail.gmail.com>
To: adiabat <rx@awsomnet.org>
Content-Type: multipart/alternative; boundary=001a114fe714473cc305453945ae
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
performance and SPV security
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: Tue, 03 Jan 2017 23:46:03 -0000
--001a114fe714473cc305453945ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
If the sender doesn't control the receiver's network connection, then the
information the receiver gains by watching the mempool is if the
transaction has propagated across the bitcoin network. This is useful to
know in all kinds of situations.
Aaron Voisine
co-founder and CEO
breadwallet <http://breadwallet.com>
On Tue, Jan 3, 2017 at 3:06 PM, adiabat <rx@awsomnet.org> wrote:
> Mempool transactions have their place, but "unconfirmed" and "SPV" don't
> belong together. Only a full node can tell if a transaction may get
> confirmed, or is nonsense. Unfortunately all the light / SPV wallets I
> know of show mempool transactions, which makes it hard to go back... (e.g=
.
> "why doesn't your software show 0-conf! your wallet is broken!", somewhat
> akin to people complaining about RBF)
>
> So, this is easy, just don't worry about mempool filtering. Why are ligh=
t
> clients looking at the mempool anyway? Maybe if there were some way to
> provide SPV proofs of all inputs, but that's a bit of a mess for full nod=
es
> to do.
>
> Without mempool filtering, I think the committed bloom filters would be a
> great improvement over the current bloom filter setup, especially for
> lightning network use cases (with lightning, not finding out about a
> transaction can make you lose money). I want to work on it and may be ab=
le
> to at some point as it's somewhat related to lightning.
>
> Also, if you're running a light client, and storing the filters the way
> you store block headers, there's really no reason to go all the way back =
to
> height 0. You can start grabbing headers at some point a while ago, befo=
re
> your set of keys was generated. I think it'd be very worth it even with
> GB-scale disk usage.
>
> -Tadge
>
>
> On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisine via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Unconfirmed transactions are incredibly important for real world use.
>> Merchants for instance are willing to accept credit card payments of
>> thousands of dollars and ship the goods despite the fact that the
>> transaction can be reversed up to 60 days later. There is a very large c=
ost
>> to losing the ability to have instant transactions in many or even most
>> situations. This cost is typically well above the fraud risk.
>>
>> It's important to recognize that bitcoin serves a wide variety of use
>> cases with different profiles for time sensitivity and fraud risk.
>>
>> Aaron
>>
>> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> The concept combined with the weak blocks system where miners commit
>>>
>>> to potential transaction inclusion with fractional difficulty blocks
>>>
>>> is possible. I'm not personally convinced that unconfirmed transaction
>>>
>>> display in a wallet is worth the privacy trade-off. The user has very
>>>
>>> little to gain from this knowledge until the txn is in a block.
>>>
>>>
>>>
>>>
>>>
>>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>>>
>>> > Hi
>>>
>>> >> We introduce several concepts that rework the lightweight Bitcoin
>>>
>>> >> client model in a manner which is secure, efficient and privacy
>>>
>>> >> compatible.
>>>
>>> >>
>>>
>>> >> The BFD can be used verbatim in replacement of BIP37, where the filt=
er
>>>
>>> >> can be cached between clients without needing to be recomputed. It c=
an
>>>
>>> >> also be used by normal pruned nodes to do re-scans locally of their
>>>
>>> >> wallet without needing to have the block data available to scan, or
>>>
>>> >> without reading the entire block chain from disk.
>>>
>>> > I started exploring the potential of BFD after this specification.
>>>
>>> >
>>>
>>> > What would be the preferred/recommended way to handle 0-conf/mempool
>>>
>>> > filtering =E2=80=93 if & once BDF would have been deployed (any type,
>>>
>>> > semi-trusted oracles or protocol-level/softfork)?
>>>
>>> >
>>>
>>> > From the user-experience perspective, this is probably pretty importa=
nt
>>>
>>> > (otherwise the experience will be that incoming funds can take serval
>>>
>>> > minutes to hours until they appear).
>>>
>>> > Using BIP37 bloom filters just for mempool filtering would obviously
>>>
>>> > result in the same unwanted privacy-setup.
>>>
>>> >
>>>
>>> > </jonas>
>>>
>>> >
>>>
>>> >
>>>
>>> > _______________________________________________
>>>
>>> > 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
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--001a114fe714473cc305453945ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If the sender doesn't control the receiver's netwo=
rk connection, then the information the receiver gains by watching the memp=
ool is if the transaction has propagated across the bitcoin network. This i=
s useful to know in all kinds of situations.</div><div class=3D"gmail_extra=
"><br clear=3D"all"><div><div class=3D"gmail_signature" data-smartmail=3D"g=
mail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr=
"><div><br>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 Tue, Jan 3, 2017 at 3:06 PM, adiabat <spa=
n dir=3D"ltr"><<a href=3D"mailto:rx@awsomnet.org" target=3D"_blank">rx@a=
wsomnet.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><span style=3D"font-size:12.8px">Mempool transactions have their =
place, but "unconfirmed" and "SPV" don't belong tog=
ether.=C2=A0 Only a full node can tell if a transaction may get confirmed, =
or is nonsense.=C2=A0 Unfortunately all the light / SPV wallets I know of s=
how mempool transactions, which makes it hard to go back... (e.g. "why=
doesn't your software show 0-conf! your wallet is broken!", somew=
hat akin to people complaining about RBF)</span><div><span style=3D"font-si=
ze:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">So, this =
is easy, just don't worry about mempool filtering.=C2=A0 Why are light =
clients looking at the mempool anyway?=C2=A0 Maybe if there were some way t=
o provide SPV proofs of all inputs, but that's a bit of a mess for full=
nodes to do.<br></span><div><span style=3D"font-size:12.8px"><br>Without m=
empool filtering, I think the committed bloom filters would be a great impr=
ovement over the current bloom filter setup, especially for lightning netwo=
rk use cases (with lightning, not finding out about a transaction can make =
you lose money).=C2=A0 I want to work on it and may be able to at some poin=
t as it's somewhat related to lightning.</span></div><div><span style=
=3D"font-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px=
">Also, if you're running a light client, and storing the filters the w=
ay you store block headers, there's really no reason to go all the way =
back to height 0.=C2=A0 You can start grabbing headers at some point a whil=
e ago, before your set of keys was generated.=C2=A0 I think it'd be ver=
y worth it even with GB-scale disk usage.</span></div><div><span style=3D"f=
ont-size:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">-Ta=
dge</span></div><div><span style=3D"font-size:12.8px"><br></span></div></di=
v></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Tue, Jan 3, 2017 at 5:18 PM, Aaron Voisin=
e via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundat=
ion.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>Unconf=
irmed transactions are incredibly important for real world use. Merchants f=
or instance are willing to accept credit card payments of thousands of doll=
ars and ship the goods despite the fact that the transaction can be reverse=
d up to 60 days later. There is a very large cost to losing the ability to =
have instant transactions in many or even most situations. This cost is typ=
ically well above the fraud risk.=C2=A0</div><div><br></div><div>It's i=
mportant to recognize that bitcoin serves a wide variety of use cases with =
different profiles for time sensitivity and fraud risk.</div><div><br></div=
><div>Aaron</div><div class=3D"m_949038359825094764HOEnZb"><div class=3D"m_=
949038359825094764h5"><div><br><div class=3D"gmail_quote"><div>On Tue, Jan =
3, 2017 at 12:41 PM bfd--- via bitcoin-dev <<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
a<wbr>tion.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The c=
oncept combined with the weak blocks system where miners commit<br class=3D=
"m_949038359825094764m_582444580811563830gmail_msg"><br>to potential transa=
ction inclusion with fractional difficulty blocks<br class=3D"m_94903835982=
5094764m_582444580811563830gmail_msg"><br>is possible. I'm not personal=
ly convinced that unconfirmed transaction<br class=3D"m_949038359825094764m=
_582444580811563830gmail_msg"><br>display in a wallet is worth the privacy =
trade-off. The user has very<br class=3D"m_949038359825094764m_582444580811=
563830gmail_msg"><br>little to gain from this knowledge until the txn is in=
a block.<br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><b=
r><br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br><br c=
lass=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>On 2017-01-0=
1 13:01, Jonas Schnelli via bitcoin-dev wrote:<br class=3D"m_94903835982509=
4764m_582444580811563830gmail_msg"><br>> Hi<br class=3D"m_94903835982509=
4764m_582444580811563830gmail_msg"><br>>> We introduce several concep=
ts that rework the lightweight Bitcoin<br class=3D"m_949038359825094764m_58=
2444580811563830gmail_msg"><br>>> client model in a manner which is s=
ecure, efficient and privacy<br class=3D"m_949038359825094764m_582444580811=
563830gmail_msg"><br>>> compatible.<br class=3D"m_949038359825094764m=
_582444580811563830gmail_msg"><br>>><br class=3D"m_949038359825094764=
m_582444580811563830gmail_msg"><br>>> The BFD can be used verbatim in=
replacement of BIP37, where the filter<br class=3D"m_949038359825094764m_5=
82444580811563830gmail_msg"><br>>> can be cached between clients with=
out needing to be recomputed. It can<br class=3D"m_949038359825094764m_5824=
44580811563830gmail_msg"><br>>> also be used by normal pruned nodes t=
o do re-scans locally of their<br class=3D"m_949038359825094764m_5824445808=
11563830gmail_msg"><br>>> wallet without needing to have the block da=
ta available to scan, or<br class=3D"m_949038359825094764m_5824445808115638=
30gmail_msg"><br>>> without reading the entire block chain from disk.=
<br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>> I =
started exploring the potential of BFD after this specification.<br class=
=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>><br class=3D=
"m_949038359825094764m_582444580811563830gmail_msg"><br>> What would be =
the preferred/recommended way to handle 0-conf/mempool<br class=3D"m_949038=
359825094764m_582444580811563830gmail_msg"><br>> filtering =E2=80=93 if =
& once BDF would have been deployed (any type,<br class=3D"m_9490383598=
25094764m_582444580811563830gmail_msg"><br>> semi-trusted oracles or pro=
tocol-level/softfork)?<br class=3D"m_949038359825094764m_582444580811563830=
gmail_msg"><br>><br class=3D"m_949038359825094764m_582444580811563830gma=
il_msg"><br>> From the user-experience perspective, this is probably pre=
tty important<br class=3D"m_949038359825094764m_582444580811563830gmail_msg=
"><br>> (otherwise the experience will be that incoming funds can take s=
erval<br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>&g=
t; minutes to hours until they appear).<br class=3D"m_949038359825094764m_5=
82444580811563830gmail_msg"><br>> Using BIP37 bloom filters just for mem=
pool filtering would obviously<br class=3D"m_949038359825094764m_5824445808=
11563830gmail_msg"><br>> result in the same unwanted privacy-setup.<br c=
lass=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>><br clas=
s=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>> </jonas=
><br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>>=
;<br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>><b=
r class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>> ____=
__________________________<wbr>_________________<br class=3D"m_949038359825=
094764m_582444580811563830gmail_msg"><br>> bitcoin-dev mailing list<br c=
lass=3D"m_949038359825094764m_582444580811563830gmail_msg"><br>> <a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"m_94903835982509=
4764m_582444580811563830gmail_msg" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundat<wbr>ion.org</a><br class=3D"m_949038359825094764m_5824445808115638=
30gmail_msg"><br>> <a href=3D"https://lists.linuxfoundation.org/mailman/=
listinfo/bitcoin-dev" rel=3D"noreferrer" class=3D"m_949038359825094764m_582=
444580811563830gmail_msg" target=3D"_blank">https://lists.linuxfoundation.<=
wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br class=3D"m_949038359825094=
764m_582444580811563830gmail_msg"><br>______________________________<wbr>__=
_______________<br class=3D"m_949038359825094764m_582444580811563830gmail_m=
sg"><br>bitcoin-dev mailing list<br class=3D"m_949038359825094764m_58244458=
0811563830gmail_msg"><br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" class=3D"m_949038359825094764m_582444580811563830gmail_msg" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br class=3D"m_94=
9038359825094764m_582444580811563830gmail_msg"><br><a href=3D"https://lists=
.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" class=
=3D"m_949038359825094764m_582444580811563830gmail_msg" target=3D"_blank">ht=
tps://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><=
br class=3D"m_949038359825094764m_582444580811563830gmail_msg"><br></blockq=
uote></div></div>
</div></div><br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
--001a114fe714473cc305453945ae--
|
