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
|
Return-Path: <erik.lite@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 46892707
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Jun 2017 13:41:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f54.google.com (mail-it0-f54.google.com
[209.85.214.54])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 925B518F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Jun 2017 13:41:56 +0000 (UTC)
Received: by mail-it0-f54.google.com with SMTP id b205so21026282itg.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Jun 2017 06:41:56 -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
:cc; bh=KaEtUMv6ZB2zpWZcE2ysabYB5J2LRBRID+hCbqVNY0A=;
b=ojvNl85faAG76vf9auVEcv8JJPQeF7JGuCIt7U2CJ5IpQLJWVyP+lnwrDfRheoCjSt
tSUT8qTaFRpUdejAe2GMQYYTRmy2eMsNE+WBAa8631+KAOCcx01WCJIEsu+UajJU/qBv
P1zkcwiUYaal3xUUEZqzOWTO3bAisXv3DwRxYht33Kx1CyuYIpe1upyt0uz16CGJkgg6
CBF/wEwvq2F2WkuA36ZVVLSBRmIl1EljH86Uocy2EGxb1eqvCtmJtDRroP5PYze2hJUk
qAfiVuUr0rCSpDS5PsjOaahmVQLIhq49mLUG7I7u2ddcSX0QwnSGJrCjwvcKboP9XNeX
keYQ==
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=KaEtUMv6ZB2zpWZcE2ysabYB5J2LRBRID+hCbqVNY0A=;
b=nyTjbts6Kxnc164NUJNHN2f6qZwcYgLDdANV/E0tEov5gmtH7vCCxU1pvVKC6EFOnH
AbjzQdvU+D+DduBXjyEoFfh+DYlRyZ6QU9ULOvdLykAVkCmEfk8Xhy4UqwsJOaS6ez0F
2fobz76cRsPpMVSF/8N6nGFhIxAWrbMPSjRBwrdJeM2ZPTYn4610L7aJQhOca5I3apWF
Yc9YoILYDAFcy8Cf070rew0mbWGqfvP6d0jsRChsdYi1V9+C6mtB4P3ETWgHVy1Wcxtt
QBHm3a9AMJG9aVcx3kORgZdfM+xH/rpnYfJicmtYaDgrnziaufsu4hLwcgEju5ORxMnu
h03A==
X-Gm-Message-State: AKS2vOzbE3WA/U1yLnvqdvL9wFms4zQXWPtaGpL7Ms+vtEKB3vns/l7W
6vMokwWx17tk0+kmHpT7fzEJ3YSTSQ==
X-Received: by 10.36.44.136 with SMTP id i130mr2121043iti.42.1498138915819;
Thu, 22 Jun 2017 06:41:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.33.80 with HTTP; Thu, 22 Jun 2017 06:41:55 -0700 (PDT)
In-Reply-To: <CADc9zGD6mGMzUgsJ5QOnXwe9X7jgjZz1WTB7RqK_kxCoRfhXBA@mail.gmail.com>
References: <CA+Yhp0Uv3zrg28G7QcgXPSv4Md9j2U-=SROJqWAOqvW_tCu=bQ@mail.gmail.com>
<CADc9zGD6mGMzUgsJ5QOnXwe9X7jgjZz1WTB7RqK_kxCoRfhXBA@mail.gmail.com>
From: Ilya Eriklintsev <erik.lite@gmail.com>
Date: Thu, 22 Jun 2017 16:41:55 +0300
Message-ID: <CA+Yhp0UeiUV5sXpMN-D5uyog2SZcpHbWELecwqMaPV3AsXpo=w@mail.gmail.com>
To: Conrad Burchert <conrad.burchert@googlemail.com>
Content-Type: multipart/alternative; boundary="001a113fa266e6e09b05528ca5ab"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
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: Thu, 22 Jun 2017 13:44:17 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Idea : DDoS resistance via decentrilized
proof-of-work
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: Thu, 22 Jun 2017 13:41:58 -0000
--001a113fa266e6e09b05528ca5ab
Content-Type: text/plain; charset="UTF-8"
Thank you, Conrad, for the feedback and I think I can see your points
clearly, but I would disagree that decentralised proof-of-work doesn't
change game rules drastically.
You are correct about proof-of-work market splitting into
"transaction-miners" and "blockchain-miners", but this is not just another
way to pay the fees, it's actually completely different mechanism. Here are
some arguments that might be able to convince you or at least to question
your premises:
1. Since bitcoin mining is a game in which winner takes it all, modified
proof-of-work will introduce a new tradeoff for the miners: either you
collect more fees (increasing risk of losing reward) or you collect more
proof-of-work (increasing reward win probability). This will create the
missing economic link between transaction fees (BTC) and proof-of-work
security costs (Hashcash PoW), creating the secondary market of
transaction-mining-capable hash power / BTC. It feels like some new game
dynamics arise in this setting, but I haven't run any numerical simulations
yet, though I'm going to do so.
2. Why is it possible to stop spam and DDoS of the network? The reason is
that to generate transaction proof-of-work user have to spend some physical
time (not money). After the user found out previous block hash he has two
choices: either to start doing some work (probably with the help of
transaction miners AND money) or instantly adjust fee at every moment (only
money). This adds a new signalling mechanism alongside standard fee market,
which will make it possible for miners to filter and do not propagate
transactions with PoW less than some handicap value (of course they can
always agree on some whitelist of non-spammers), thus preventing abuse of
spammer transactions with competitive fees to delay valuable and important
transfers of BTC.
Hope I addressed all the issues you mentioned.
On 22 June 2017 at 15:02, Conrad Burchert <conrad.burchert@googlemail.com>
wrote:
> As soon as there is competition for block space, people will likely
> outsource creating the proof of work on the transaction to "transaction
> miners". This would likely result in giving a fee to those transaction
> miners. If those are the same miners as those mining the block, we are back
> at the current system.
>
> Put in other words: We are already doing this, you are paying the miner
> for a piece of the proof of work of the block. If you want to mine instead
> of paying, just mine a block and use a part of the block reward to pay the
> fee for another transaction.
>
> This also does not work to prevent spam. Instead of paying the transaction
> fee you can just pay someone to mine proof-of-work on your spam
> transactions, resulting in roughly the same cost. There is no reason a
> normal user would be better in doing this than a spammer, likely it is the
> other way around as the spammer is a more reliable customer for a miner.
>
> 2017-06-21 11:55 GMT+02:00 Ilya Eriklintsev via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>:
>
>> Hello everyone,
>>
>> recently I have got an idea that in my opinion will improve bitcoin
>> network, making it better store-of-value for growing cyberspace and
>> cryptoeconomy. Sorry for longread below and thank you for your time.
>>
>> *Decentralized proof-of-work and DDoS resistance for Bitcoin*
>>
>> *Abstract*
>>
>> By introducing some new block validation rules it is possible to make
>> Bitcoin network more secure, decentralized and DDoS resistant. The idea is
>> to modify simple proof-of-work puzzle in such a way that user transactions
>> could be hardened with the same proof-of-work algorithm thus incentivising
>> all the miners to include that particular transaction. Such mechanism will
>> effectively give a handicap to every miner who includes "mined" transaction
>> into next block, increasing probability of him getting block reward.
>>
>> *Problems and motivation*
>>
>> This document will address the issue of a continuous DDoS attack
>> targeting the Bitcoin network, e.g. full nodes mempools constantly being
>> overflowed with transactions carrying small value reduce system primary
>> ability to transfer value (and hence making it perfect store of value).
>> Valid transactions are cheap to create (in the sense of computational
>> effort required) and no adequate mechanism exist to make transaction total
>> value increase probably of its confirmation by the network.
>>
>> Currently, miners decide which transactions to include in blocks because
>> it's them who are securing Bitcoin network providing proof-of-work
>> certificates stored inside every block header. Miners have to store the
>> whole blockchain at all times, so one of the costs is storage which grows
>> linearly with the transaction size (blockchain size as well). Another cost
>> is network bandwidth which depends directly on the size of data to be
>> communicated over.
>>
>> The only incentive a person who wants to transfer his bitcoins is allowed
>> to use is setting of transaction fee, that is going directly to the miner.
>> This solution probably was intended to utilize free market (as implied by
>> Satoshi introducing sequence numbers) to determine appropriate fees, but
>> that is obviously not the case, in the current bitcoin network operating in
>> full block capacity mode. This fee market deviates significantly from a
>> free market premise (also attempts being made to make it closer, e.g. in
>> BIP125 where Replace-By-Fee signaling is supposed to help in replacing
>> "stuck" transactions with noncompetitive fee).
>>
>> Currently, bitcoin network is susceptible to the DDoS attack of a kind.
>> Adversary creating and translating into the network a lot of transactions
>> carrying small value (e.g. only miners fee), will be able to impair the
>> ability to transfer value for everyone in the world, should he has enough
>> money to pay the fees. Miners would continue to work providing security for
>> the network and new blocks will consist of transaction transferring
>> negligible value. It's a major drawback because the cost of such attack
>> doesn't grow asymmetrically with the cost of BTC asset.
>>
>> *Proposed solution*
>>
>> So how do we incentivize all miners to include our transaction carrying a
>> lot of value in the next block? The only thing a miner supposed to do to
>> get a reward is to produce Hashcash proof-of-work, thus providing
>> cryptographic security guarantees for the whole Bitcoin blockchain. What if
>> including our transaction in a block would reduce effort requirements for
>> the miner produce valid block?
>>
>> We could do so by extending the concept of proof-of-work, in such a way
>> that we do not sacrifice security at all. Here are both descriptions
>> proof-of-work as-is and to-be:
>>
>> Standart proof-of-work: hash(previous block hash + current block target +
>> current block metadata + current block transactions) < target
>>
>> Decentralized proof-of-work: hash(previous block hash + current block
>> target + current block metadata + current block transactions) - sum( FFFF -
>> hash( previous block hash + raw_tx ) ) < target
>>
>> It is possible to imagine completely mining agnostic proof-of-work, for
>> example, the following PoW would do:
>>
>> Distributed (mining-agnostic) proof-of-work: sum( FFFF - hash( previous
>> block hash + current block target + current block metadata + signed_tx ) )
>> < target
>>
>> Described protocol change could be implemented as user activated
>> soft-fork (described in BIP148), introducing new blocks with the modified
>> proof-of-work concept.
>>
>> *Economic reasoning*
>>
>> An adversary whose goal is to prevent the network from transferring value
>> will have to compete with good users hash rate using same equipment good
>> miners will use. And it's far more complicated than competing with others
>> using the money to pay transaction fees.
>>
>> In order to investigate probable consequences of protocol upgrade and
>> stability of implied economical equilibrium, we need an adequate game
>> theoretical model. Such model and numerical simulation results should be
>> obtained and studied before any protocol change could be considered by the
>> community.
>>
>> To me it seems like a win-win solution for everyone owning BTC:
>>
>> Miners benefit: as the result DDoS attack will be stopped, Bitcoin
>> becomes perfect store-of-value finally. Political decentralization of hash
>> rate will be incentivized as mining equipment becomes relevant to every
>> user.
>> Users benefit: miners will have direct incentives to include transactions
>> deemed important by their sender and supported by some amount of
>> proof-of-work.
>>
>> Sincerely yours, Ilya Eriklintsev.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--001a113fa266e6e09b05528ca5ab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thank you, Conrad, for the feedback and I think I can see =
your points clearly, but I would disagree that decentralised proof-of-work =
doesn't change game rules drastically.<br><div>You are correct about pr=
oof-of-work market splitting into "transaction-miners" and "=
blockchain-miners", but this is not just another way to pay the fees, =
it's actually completely different=C2=A0mechanism. Here are some argume=
nts=C2=A0that might be able to convince you or at least to question your pr=
emises:</div><div><br></div><div>1. Since bitcoin mining is a game in which=
winner takes it all, modified proof-of-work will introduce a new tradeoff =
for the miners: either you collect more fees (increasing risk of losing rew=
ard) or you collect more proof-of-work (increasing reward win probability).=
This will create the missing economic link between transaction fees (BTC) =
and proof-of-work security costs (Hashcash PoW), creating the=C2=A0secondar=
y market of transaction-mining-capable hash power / BTC. It feels=C2=A0like=
some new game dynamics arise in this setting, but I haven't run any nu=
merical simulations yet, though I'm going to do so.=C2=A0</div><div><br=
></div><div>2. Why is it possible to stop spam and DDoS of the network? The=
reason is that to generate transaction=C2=A0proof-of-work user have to spe=
nd some physical time (not money). After the user found out previous block =
hash he has two choices: either to start doing some work (probably with the=
help of transaction miners AND money) or instantly adjust fee at every mom=
ent (only money). This adds a new signalling mechanism alongside standard f=
ee market, which will make it possible for miners to filter and do not prop=
agate transactions with PoW less than some handicap value (of course they c=
an always agree on some whitelist of non-spammers), thus preventing abuse o=
f spammer transactions with competitive fees to=C2=A0delay valuable and imp=
ortant transfers of BTC.</div><div><br></div><div>Hope I addressed all the =
issues you mentioned.</div><div><br></div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On 22 June 2017 at 15:02, Conrad Burchert <s=
pan dir=3D"ltr"><<a href=3D"mailto:conrad.burchert@googlemail.com" targe=
t=3D"_blank">conrad.burchert@googlemail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr">As soon as there is competition f=
or block space, people will likely outsource creating the proof of work on =
the transaction to "transaction miners". This would likely result=
in giving a fee to those transaction miners. If those are the same miners =
as those mining the block, we are back at the current system.<div><br></div=
><div>Put in other words: We are already doing this, you are paying the min=
er for a piece of the proof of work of the block. If you want to mine inste=
ad of paying, just mine a block and use a part of the block reward to pay t=
he fee for another transaction.</div><div><br></div><div>This also does not=
work to prevent spam. Instead of paying the transaction fee you can just p=
ay someone to mine proof-of-work on your spam transactions, resulting in ro=
ughly the same cost. There is no reason a normal user would be better in do=
ing this than a spammer, likely it is the other way around as the spammer i=
s a more reliable customer for a miner.</div></div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote"><div><div class=3D"h5">2017-06-21 11:55 G=
MT+02:00 Ilya Eriklintsev via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.<wbr>linuxfoundation.org</a>></span>:<br></div></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div><div class=3D"h5"><div dir=3D"ltr"><span style=3D"f=
ont-size:12.8px">Hello everyone,</span><div style=3D"font-size:12.8px"><br>=
<div>recently I have got an idea that in my opinion will improve bitcoin ne=
twork, making it better store-of-value for growing cyberspace and cryptoeco=
nomy. Sorry for longread=C2=A0below and thank you for your time.<div><br></=
div><b>Decentralized proof-of-work and DDoS resistance for Bitcoin</b><br><=
br><b>Abstract</b><br><br>By introducing some new block validation rules it=
is possible to make Bitcoin network more secure, decentralized and DDoS re=
sistant. The idea is to modify simple proof-of-work puzzle in such a way th=
at user transactions could be hardened with the same proof-of-work algorith=
m thus incentivising all the miners to include that particular transaction.=
Such mechanism will effectively give a handicap to every miner who include=
s "mined" transaction into next block, increasing probability of =
him getting block reward.<br><br><b>Problems and motivation</b><br><br>This=
document will address the issue of a continuous DDoS attack targeting the =
Bitcoin network, e.g. full nodes mempools constantly being overflowed with =
transactions carrying small value reduce system primary ability to transfer=
value (and hence making it perfect store of value). Valid transactions are=
cheap to create (in the sense of computational effort required) and no ade=
quate mechanism exist to make transaction total value increase probably of =
its confirmation by the network.<br><br>Currently, miners decide which tran=
sactions to include in blocks because it's them who are securing Bitcoi=
n network providing proof-of-work certificates stored inside every block he=
ader. Miners have to store the whole blockchain at all times, so one of the=
costs is storage which grows linearly with the transaction size (blockchai=
n size as well). Another cost is network bandwidth which depends directly o=
n the size of data to be communicated over.<br><br>The only incentive a per=
son who wants to transfer his bitcoins is allowed to use is setting of tran=
saction fee, that is going directly to the miner. This solution probably wa=
s intended to utilize free market (as implied by Satoshi introducing sequen=
ce numbers) to determine appropriate fees, but that is obviously not the ca=
se, in the current bitcoin network operating in full block capacity mode. T=
his fee market deviates significantly from a free market premise (also atte=
mpts being made to make it closer, e.g. in BIP125 where Replace-By-Fee sign=
aling is supposed to help in replacing "stuck" transactions with =
noncompetitive fee).<br><br>Currently, bitcoin network is susceptible to th=
e DDoS attack of a kind. Adversary creating and translating into the networ=
k a lot of transactions carrying small value (e.g. only miners fee), will b=
e able to impair the ability to transfer value for everyone in the world, s=
hould he has enough money to pay the fees. Miners would continue to work pr=
oviding security for the network and new blocks will consist of transaction=
transferring negligible value. It's a major drawback because the cost =
of such attack doesn't grow asymmetrically with the cost of BTC asset.<=
br><br><b>Proposed solution</b><br><br>So how do we incentivize all miners =
to include our transaction carrying a lot of value in the next block? The o=
nly thing a miner supposed to do to get a reward is to produce Hashcash pro=
of-of-work, thus providing cryptographic security guarantees for the whole =
Bitcoin blockchain. What if including our transaction in a block would redu=
ce effort requirements for the miner produce valid block?<br><br>We could d=
o so by extending the concept of proof-of-work, in such a way that we do no=
t sacrifice security at all. Here are both descriptions proof-of-work as-is=
and to-be:<br><br>Standart proof-of-work: hash(previous block hash + curre=
nt block target + current block metadata + current block transactions) <=
target<br><br>Decentralized proof-of-work: hash(previous block hash + curr=
ent block target + current block metadata + current block transactions) - s=
um( FFFF - hash( previous block hash + raw_tx ) ) < target<br><br>It is =
possible to imagine completely mining agnostic proof-of-work, for example, =
the following PoW would do:<br><br>Distributed (mining-agnostic) proof-of-w=
ork: sum( FFFF - hash( previous block hash + current block target + current=
block metadata + signed_tx ) ) < target<br><br>Described protocol chang=
e could be implemented as user activated soft-fork (described in BIP148), i=
ntroducing new blocks with the modified proof-of-work concept.<br><b><br>Ec=
onomic reasoning</b><br><br>An adversary whose goal is to prevent the netwo=
rk from transferring value will have to compete with good users hash rate u=
sing same equipment good miners will use. And it's far more complicated=
than competing with others using the money to pay transaction fees.<br><br=
>In order to investigate probable consequences of protocol upgrade and stab=
ility of implied economical equilibrium, we need an adequate game theoretic=
al model. Such model and numerical simulation results should be obtained an=
d studied before any protocol change could be considered by the community.<=
br><br>To me it seems like a win-win solution for everyone owning BTC:<br><=
br>Miners benefit: as the result DDoS attack will be stopped, Bitcoin becom=
es perfect store-of-value finally. Political decentralization of hash rate =
will be incentivized as mining equipment becomes relevant to every user.<br=
>Users benefit: miners will have direct incentives to include transactions =
deemed important by their sender and supported by some amount of proof-of-w=
ork.</div><div><br></div><div>Sincerely yours, Ilya Eriklintsev.</div></div=
></div>
<br></div></div>______________________________<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>
</blockquote></div><br></div>
--001a113fa266e6e09b05528ca5ab--
|