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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6CB829EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 11:48:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f174.google.com (mail-io0-f174.google.com
[209.85.223.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9B3AAA1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 11:48:13 +0000 (UTC)
Received: by mail-io0-f174.google.com with SMTP id m103so7636942iod.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 15 Sep 2017 04:48:13 -0700 (PDT)
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;
bh=KWJ7XV37mmqX2/5YpyjAhyn2p7JEE5t8UlcFdbH3pug=;
b=G33QcXAXXn5uLCRw+VNee+eCnWzwJfPs2FxUq/Lm7j+YgJdefanDDsQW1ygrS1w7Mv
VOwLdYMI4BIfqT0FeADS77eCX4jxqe5GqNvaZoMUujMZ7McWMMfJpXubkEOCrZb5v3zr
7Ie6teIDEyTZBWBQozDwXgfPM/gY1ZlUh8mPO4zkLV2lm7sfnovHmFwB8HFhSetSCeCP
knTxepfpEYzDphj1gAmjOvCEfnLqkFsaKgSu1ibX+4X3+1N7ZCr7BD4IJnrPiC0hFpxi
cOJNcA5ZmQ5DyyVYmb5IELNsuAdGMNBexrhgCfutP+ipZNQz51r28rcCHjPpP3UKBiDG
cMkA==
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;
bh=KWJ7XV37mmqX2/5YpyjAhyn2p7JEE5t8UlcFdbH3pug=;
b=dKPdLF1m7TetansX39FLpcyKRoZBEeBcF+CgWqSAhnAPxrGhb+Lv3Iy8yN6xEtxh2o
KGffSdwj4Yy3bcriCdm1qUepUouNmFm8BbuKDNS9UP+VPbh8oLkECh+53b+cYZ95M1AR
0tLAM0UgYwknH3jrAopUn/EDe70f15nMVHu1tDWMA3VONYVW77dL5mqmgayuG4SVk5fN
tlM2VcVqa2QPTzyVNOaQYZOKzapBk0fTWu4hn1xCd3ZvcnFDi4+3ipO8D6u9yhN4C2KX
84bvCIWGfZQqklG6eMLN5NJM8v69qOjRiTn6zvhsc7K6S85q1GiMTYaEqFGdpLQtvAWz
edmg==
X-Gm-Message-State: AHPjjUiT77oQMI7xHFBA5mshbXz8E3qcx0C1yYPLkB/nYGqrChw4Kopz
h9/o4IYdsc/MT97BwMdSdreTgRThubpgiAr8eCgPYw==
X-Google-Smtp-Source: AOwi7QAhuItf5QLh8JfQv7ecH5jtlccC/ipDJJhgqgJAUqdmbHFrM8tQRu/15bVQ711R3QWiZPeFHT3gPpseHYeWW30=
X-Received: by 10.202.179.137 with SMTP id c131mr16069200oif.175.1505476092728;
Fri, 15 Sep 2017 04:48:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.155.136 with HTTP; Fri, 15 Sep 2017 04:47:32 -0700 (PDT)
In-Reply-To: <CALqxMTFEA2X0GJwF8rO=8twsgW=brrzScpDD=owiK9otocdjoA@mail.gmail.com>
References: <9e212eae-08d5-d083-80d9-a8e29679fcdc@osc.co.cr>
<SU02clg--S4TtIK4TZIytgdnHE8SzXBwSEb_FN5edtPAaojLwCEd6OTNkBUrDiH1FwHPuD4D5yByE7r4Fz_-CVzzU9KK0xvmDGlWNxTp3aU=@protonmail.com>
<CALqxMTFEA2X0GJwF8rO=8twsgW=brrzScpDD=owiK9otocdjoA@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Fri, 15 Sep 2017 12:47:32 +0100
Message-ID: <CAE-z3OWJo07mpsyZEqfBV_T55jbB+2Ur0JeO2hSqOb2g_19F4Q@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a113ce08cb999d4055938f75a"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
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, 15 Sep 2017 11:48:14 -0000
--001a113ce08cb999d4055938f75a
Content-Type: text/plain; charset="UTF-8"
On Fri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> True however in principle a soft-fork can also be soft-forked out. Eg say
> a publicly known soft-fork done by miners only that user node software did
> not upgrade for first by opt-in adoption.
>
It depends on what software that the general user-base is using (especially
exchanges). If a majority of miners have deployed a hidden soft fork, then
the soft fork will only last as long as they can maintain their majority.
If they drop below 50%, then the majority of miners will eventually make
and then build on a block that is invalid according to their hidden soft
fork rules.
If the userbase doesn't support a censorship soft fork, then it will only
last as long as a majority of miners support it. Once the cartel loses its
majority, there is a strong incentive for members to disable their soft
fork rule. Any that don't will end up mining a lower POW, but valid, chain.
Users updating their nodes to enforce the soft fork is what makes the soft
fork irreversible (without a hard fork).
> A censorship soft-fork is harder, that's a standard hard-fork to bypass
> with current fungibility mechanisms.
>
It's only a hard fork to reverse if the community is enforcing the soft
fork. Forking off a minority of miners doesn't make it a hard fork.
>
> Adam
>
> On Sep 15, 2017 08:12, "ZmnSCPxj via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> Good morning Dan,
>>
>> My understanding is that it is impossible for soft forks to be prevented.
>>
>> 1. Anyone-can-spend
>>
>> There are a very large number of anyone-can-spend scripts, and it would
>> be very impractical to ban them all.
>>
>> For example, the below output script is anyone-can-spend
>>
>> <random number> OP_TRUE
>>
>> So is the below:
>>
>> OP_SIZE <random small number> OP_EQUAL
>>
>> Or:
>>
>> OP_1ADD <random number> OP_EQUAL
>>
>> Or:
>>
>> OP_BOOLAND
>>
>> Or:
>>
>> OP_BOOLOR
>>
>> And so on.
>>
>> So no, it is not practically possible to ban anyone-can-spend outputs, as
>> there are too many potential scriptPubKey that anyone can spend.
>>
>> It is even possible to have an output that requires a proof-of-work, like
>> so:
>>
>> OP_HASH256 <difficulty target> OP_LESSTHAN
>>
>> All the above outputs are disallowed from propagation by IsStandard, but
>> a miner can put them validly in a block, and IsStandard is not consensus
>> code and can be modified.
>>
>> 2. Soft fork = restrict
>>
>> It is possible (although unlikely) for a majority of miners to run soft
>> forking code which the rest of us are not privy to.
>>
>> For example, for all we know, miners are already blacklisting spends on
>> Satoshi's coins. We would not be able to detect this at all, since no
>> transaction that spends Satoshi's coins have been broadcast, ever. It is
>> thus indistinguishable from a world where Satoshi lost his private keys.
>> Of course, the world where Satoshi never spent his coins and miners are
>> blacklisting Satoshi's coins, is more complex than the world where Satoshi
>> never spent his coins, so it is more likely that miners are not
>> blacklisting.
>>
>> But the principle is there. We may already be in a softfork whose rules
>> we do not know, and it just so happens that all our transactions today do
>> not violate those rules. It is impossible for us to know this, but it is
>> very unlikely.
>>
>> Soft forks apply further restrictions on Bitcoin. Hard forks do not.
>> Thus, if everyone else is entering a soft fork and we are oblivious, we do
>> not even know about it. Whereas, if everyone else is entering a hard fork,
>> we will immediately see (and reject) invalid transactions and blocks.
>>
>> Thus the only way to prevent soft fork is to hard fork against the new
>> soft fork, like Bcash did.
>>
>> Regards,
>> ZmnSCPxj
>>
>> -------- Original Message --------
>> Subject: [bitcoin-dev] hypothetical: Could soft-forks be prevented?
>> Local Time: September 13, 2017 5:50 PM
>> UTC Time: September 13, 2017 9:50 AM
>> From: bitcoin-dev@lists.linuxfoundation.org
>> To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
>>
>> Hi, I am interested in the possibility of a cryptocurrency software
>> (future bitcoin or a future altcoin) that strives to have immutable
>> consensus rules.
>>
>> The goal of such a cryptocurrency would not be to have the latest and
>> greatest tech, but rather to be a long-term store of value and to offer
>> investors great certainty and predictability... something that markets
>> tend to like. And of course, zero consensus rule changes also means
>> less chance of new bugs and attack surface remains the same, which is
>> good for security.
>>
>> Of course, hard-forks are always possible. But that is a clear split
>> and something that people must opt into. Each party has to make a
>> choice, and inertia is on the side of the status quo. Whereas
>> soft-forks sort of drag people along with them, even those who oppose
>> the changes and never upgrade. In my view, that is problematic,
>> especially for a coin with permanent consensus rule immutability as a
>> goal/ethic.
>>
>> As I understand it, bitcoin soft-forks always rely on anyone-can-spend
>> transactions. If those were removed, would it effectively prevent
>> soft-forks, or are there other possible mechanisms? How important are
>> any-one-can spend tx for other uses?
>>
>> More generally, do you think it is possible to programmatically
>> avoid/ban soft-forks, and if so, how would you go about it?
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
--001a113ce08cb999d4055938f75a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Sep 15, 2017 at 10:14 AM, Adam Back via bitcoin-dev <span dir=3D"ltr">&=
lt;<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><div dir=3D"auto">True however in =
principle a soft-fork can also be soft-forked out. Eg say a publicly known =
soft-fork done by miners only that user node software did not upgrade for f=
irst by opt-in adoption. </div></blockquote><div><br></div><div>It depends =
on what software that the general user-base is using (especially exchanges)=
.=C2=A0 If a majority of miners have deployed a hidden soft fork, then the =
soft fork will only last as long as they can maintain their majority.<br><b=
r></div><div>If they drop below 50%, then the majority of miners will event=
ually make and then build on a block that is invalid according to their hid=
den soft fork rules.<br><br></div><div></div><div>If the userbase doesn'=
;t support a censorship soft fork, then it will only last as long as a majo=
rity of miners support it.=C2=A0 Once the cartel loses its majority, there =
is a strong incentive for members to disable their soft fork rule.=C2=A0 An=
y that don't will end up mining a lower POW, but valid, chain.<br></div=
><div><br>Users updating their nodes to enforce the soft fork is what makes=
the soft fork irreversible (without a hard fork).<br>=C2=A0</div><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote"><div dir=3D"auto">A censorship sof=
t-fork is harder, that's a standard hard-fork to bypass with current fu=
ngibility mechanisms.</div></blockquote><div><br></div><div>It's only a=
hard fork to reverse if the community is enforcing the soft fork.=C2=A0 Fo=
rking off a minority of miners doesn't make it a hard fork.<br></div><d=
iv>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=
=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">Adam</div></div><di=
v class=3D"gmail-HOEnZb"><div class=3D"gmail-h5"><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sep 15, 2017 08:12, "ZmnSCPxj via b=
itcoin-dev" <<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wro=
te:<br type=3D"attribution"><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e"><div>Good morning Dan,<br></div><div><br></div><div>My understanding is =
that it is impossible for soft forks to be prevented.<br></div><div><br></d=
iv><div>1.=C2=A0 Anyone-can-spend<br></div><div><br></div><div>There are a =
very large number of anyone-can-spend scripts, and it would be very impract=
ical to ban them all.<br></div><div><br></div><div>For example, the below o=
utput script is anyone-can-spend<br></div><div><br></div><div>=C2=A0<ran=
dom number> OP_TRUE<br></div><div><br></div><div>So is the below:<br></d=
iv><div><br></div><div>=C2=A0 OP_SIZE <random small number> OP_EQUAL<=
br></div><div><br></div><div>Or:<br></div><div><br></div><div>=C2=A0 OP_1AD=
D <random number> OP_EQUAL<br></div><div><br></div><div>Or:<br></div>=
<div><br></div><div>=C2=A0 OP_BOOLAND<br></div><div><br></div><div>Or:<br><=
/div><div><br></div><div>=C2=A0 OP_BOOLOR<br></div><div><br></div><div>And =
so on.<br></div><div><br></div><div>So no, it is not practically possible t=
o ban anyone-can-spend outputs, as there are too many potential scriptPubKe=
y that anyone can spend.<br></div><div><br></div><div>It is even possible t=
o have an output that requires a proof-of-work, like so:<br></div><div><br>=
</div><div>=C2=A0OP_HASH256 <difficulty target> OP_LESSTHAN<br></div>=
<div><br></div><div>All the above outputs are disallowed from propagation b=
y IsStandard, but a miner can put them validly in a block, and IsStandard i=
s not consensus code and can be modified.<br></div><div><br></div><div>2.=
=C2=A0 Soft fork =3D restrict<br></div><div><br></div><div>It is possible (=
although unlikely) for a majority of miners to run soft forking code which =
the rest of us are not privy to.<br></div><div><br></div><div>For example, =
for all we know, miners are already blacklisting spends on Satoshi's co=
ins.=C2=A0 We would not be able to detect this at all, since no transaction=
that spends Satoshi's coins have been broadcast, ever.=C2=A0 It is thu=
s indistinguishable from a world where Satoshi lost his private keys.=C2=A0=
Of course, the world where Satoshi never spent his coins and miners are bl=
acklisting Satoshi's coins, is more complex than the world where Satosh=
i never spent his coins, so it is more likely that miners are not blacklist=
ing.<br></div><div><br></div><div>But the principle is there.=C2=A0 We may =
already be in a softfork whose rules we do not know, and it just so happens=
that all our transactions today do not violate those rules.=C2=A0 It is im=
possible for us to know this, but it is very unlikely.<br></div><div><br></=
div><div>Soft forks apply further restrictions on Bitcoin.=C2=A0 Hard forks=
do not.=C2=A0 Thus, if everyone else is entering a soft fork and we are ob=
livious, we do not even know about it.=C2=A0 Whereas, if everyone else is e=
ntering a hard fork, we will immediately see (and reject) invalid transacti=
ons and blocks.<br></div><div><br></div><div>Thus the only way to prevent s=
oft fork is to hard fork against the new soft fork, like Bcash did.<br></di=
v><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></d=
iv><div>-------- Original Message --------<br></div><div>Subject: [bitcoin-=
dev] hypothetical: Could soft-forks be prevented?<br></div><div>Local Time:=
September 13, 2017 5:50 PM<br></div><div>UTC Time: September 13, 2017 9:50=
AM<br></div><div>From: <a target=3D"_blank" href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br><=
/div><div>To: Bitcoin Protocol Discussion <<a target=3D"_blank" href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
<wbr>tion.org</a>><br></div><div><br></div><div>Hi, I am interested in t=
he possibility of a cryptocurrency software<br></div><div>(future bitcoin o=
r a future altcoin) that strives to have immutable<br></div><div>consensus =
rules.<br></div><div><br></div><div>The goal of such a cryptocurrency would=
not be to have the latest and<br></div><div>greatest tech, but rather to b=
e a long-term store of value and to offer<br></div><div>investors great cer=
tainty and predictability... something that markets<br></div><div>tend to l=
ike. And of course, zero consensus rule changes also means<br></div><div>l=
ess chance of new bugs and attack surface remains the same, which is<br></d=
iv><div>good for security.<br></div><div><br></div><div>Of course, hard-for=
ks are always possible. But that is a clear split<br></div><div>and someth=
ing that people must opt into. Each party has to make a<br></div><div>choi=
ce, and inertia is on the side of the status quo. Whereas<br></div><div>so=
ft-forks sort of drag people along with them, even those who oppose<br></di=
v><div>the changes and never upgrade. In my view, that is problematic,<br>=
</div><div>especially for a coin with permanent consensus rule immutability=
as a<br></div><div>goal/ethic.<br></div><div><br></div><div>As I understan=
d it, bitcoin soft-forks always rely on anyone-can-spend<br></div><div>tran=
sactions. If those were removed, would it effectively prevent<br></div><di=
v>soft-forks, or are there other possible mechanisms? How important are<br=
></div><div>any-one-can spend tx for other uses?<br></div><div><br></div><d=
iv>More generally, do you think it is possible to programmatically<br></div=
><div>avoid/ban soft-forks, and if so, how would you go about it?<br></div>=
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
<div>______________________________<wbr>_________________<br></div><div>bit=
coin-dev mailing list<br></div><div><a target=3D"_blank" href=3D"mailto:bit=
coin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundat<wbr>ion.=
org</a><br></div><div><a target=3D"_blank" href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>=
org/mailman/listinfo/bitcoin-d<wbr>ev</a><br></div><br>____________________=
__________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a target=3D"_blank" rel=3D"noreferrer" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
<br></blockquote></div></div>
</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 target=3D"_blank" rel=3D"noreferrer" href=3D"https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div></div>
--001a113ce08cb999d4055938f75a--
|