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
|
Return-Path: <peter_r@gmx.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3B6D3107C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 03:08:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9832A17D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Aug 2015 03:08:39 +0000 (UTC)
Received: from [192.168.50.29] ([69.50.179.106]) by mail.gmx.com (mrgmx101)
with ESMTPSA (Nemesis) id 0LoJDJ-1Z3gpn0uuf-00gG4B;
Sun, 30 Aug 2015 05:08:35 +0200
Content-Type: multipart/alternative;
boundary="Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Peter R <peter_r@gmx.com>
In-Reply-To: <55E26BDE.2080607@mattcorallo.com>
Date: Sat, 29 Aug 2015 20:08:32 -0700
Message-Id: <DCEBB396-0FBD-40B0-95F5-F9936F580E2A@gmx.com>
References: <CAEgR2PHggX-8r+FZm=pod9KQv3E3=8wo-9nOB02-YDmy5NGsZQ@mail.gmail.com>
<55E21F2E.9000308@mattcorallo.com>
<786493BB-2136-4587-A309-B8B1A34ED568@gmx.com>
<55E26B82.2070805@mattcorallo.com>
<55E26BDE.2080607@mattcorallo.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V03:K0:oA8R5tQ9PV2oLo4SdDWpu6CP+ZWrGVL/50URZbmbnALoz67x/e1
I0YH4sdV/gn5I3pxqNduLrpDipJhg6w2PT2yLHz2nUeQfb9PmnnXYWO9kHcJHqu/p5F/vmr
cjiu0mwte+EOt9zE+0m89D7q3PcBmkmXV40beEHxV+n7F9pYyt9Z7Vcn7tKO3KZga1UN4tk
DlAU5DxNwaWtYpwfxkoJg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ngMycWM9luk=:u08oMLNvZjKhoUtwYDONtq
o/uaoOTlJmQstX/bBHknmJ0sY73qTBAuXsi/m1PVM10mrq1Q1jEGbBdniF5ZvQm9V/Uja5q4f
F82+AB3atn0+b6kmWVK+axxcq3l9DeoOqMlUdYfGw2ZRvCs/6380D7UOWtYc5U6ePSHAVEoTq
Kc31MSL7D2umbZOfJTnqskc7l27SWNdWRF9A+FK/Ki0gAviNteJnapmWfxSaF3aR2caF5jpmM
/WPefzT89aMf6gNUyDuF2Ku4CJoWkLlgODcqKwdRP3vEfwEW+ikh1282fS4zbXLmjPSiVMZxX
2+RfPduLnrH2dRCm4bJbIiiFeLVAAziyjvGlS1FGQVU3QthAHWGLJLRE5HX9oUq/uj76BjvK2
BOPyJUKJSoLQxDG/wFU2lndkBRzi510F4SEdoSyxkjKNfS2iWtk7UgZ8CzoGxFgJZfagxhDic
R41eZDa9WwFTVaQ32H5qnY+r9rBLcHHO/Ugr7V8EPiUuSD7C30e6mqbAMw0dVN9ZJjsM2V1Lc
T+tIAAJ14AwDKCDbOJKjCfOTqsbiiCIBicPUTyjLVTHg+TBY6FCrwIispRfPaBdPDwQgTGiGO
99KPHodP0Dy5an8rpTN/0RWNMNDp+ihYJEXw/zBKz+l2ueK09E8d0T7jwNOgRXkZuf7poNGrQ
Pxx3W01y0d/uFGqd8IBzoShKxRyYAeRbQKVeejkK4h66qOs0yzgMXnlCynRlRqOQYQiCvWT+Z
xg3SU363j+Yv8n6MrPO9Kbkgc4VaM9h+dVeHbA==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
Cc: bitcoin-dev@lists.linuxfoundation.org,
Daniele Pinna <daniele.pinna@gmail.com>
Subject: Re: [bitcoin-dev] On the Nature of Miner Advantages in Uncapped
Block Size Fee Markets
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 30 Aug 2015 03:08:41 -0000
--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
> Of course this assumes the network does not change any as a result of
> such a system. But such a system provides strong incentives for the
> network to centralize in other ways (put all the mining nodes in one =
DC
> for all miners, etc).
If all the mining nodes are in one data center, and if all the nodes are =
programmed to build blocks in essentially the same way, then I would =
agree that the orphan cost would be negligible! I will add this as an =
example of a network configuration where the results of my paper would =
be less relevant. =20
Peter =20
On 2015-08-29, at 7:35 PM, Matt Corallo <lf-lists@mattcorallo.com> =
wrote:
> Of course this assumes the network does not change any as a result of
> such a system. But such a system provides strong incentives for the
> network to centralize in other ways (put all the mining nodes in one =
DC
> for all miners, etc).
>=20
> Matt
>=20
> On 08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:
>> It is not a purely academic scenario that blocks contain effectively =
no
>> information (that was not previously relayed). I'm not aware of any
>> public code to do so, but I know several large miners who pre-relay =
the
>> block(s) they are working on to other nodes of theirs around the =
globe.
>> This means at announce-time you have only a few bytes to broadcast =
(way
>> less than a packet, and effects of using smaller packets to relay =
things
>> vs larger packets are very small, if anything). After you've =
broadcast
>> to all of your nodes, hops to other mining nodes are probably only a
>> handful of ms away with very low packet loss, so relay time is no =
longer
>> connected to transaction inclusion at all (unless you're talking =
about
>> multi-GB blocks). Of course, this is relay time for large miners who =
can
>> invest time and money to build such systems. Small miners are =
completely
>> screwed in such a system.
>>=20
>> Thus, the orphan risk for including a transaction is related to the
>> validation time (which is only DB modify-utxo-set time, essentially,
>> which maybe you can optimize much of that away, too, and only have to
>> pass over mempool or so). Anyway, my point, really, is that though
>> miners will have an incentive to not include transactions which will
>> trigger validation by other nodes (ie things not already in their
>> mempool), the incentive to not include transactions which have =
already
>> been relayed around sufficiently is, while not theoretically zero, as
>> near to zero in practice as you can get.
>>=20
>> Matt
>>=20
>> On 08/29/15 23:17, Peter R wrote:
>>> Hello Matt and Daniele,
>>>=20
>>>> this seems to ignore the effects of transaction validation caches =
and
>>>> *block
>>>> compression protocols. *
>>>=20
>>> The effect of block compression protocols is included. This is what =
I
>>> call the "coding gain" and use the Greek letter "gamma" to =
represent.=20
>>>=20
>>> As long as the block solution announcements contain information =
(i.e.,
>>> Shannon Entropy) about the transactions included in a block, then =
the
>>> fee market will be "healthy" according to the definitions given in =
the
>>> linked paper (see below). This is the case right now, this is the =
case
>>> with your relay network, and this would be the case using any
>>> implementation of IBLTs that I can imagine, so long as miners can =
still
>>> construct blocks according to their own volition. The "healthy fee
>>> market" result follows from the Shannon-Hartley theorem; the =
SH-theorem
>>> describes the maximum rate at which information (Shannon Entropy) =
can be
>>> transmitted over a physical communication channel. =20
>>>=20
>>> https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf
>>>=20
>>> I've exchanged emails with Greg Maxwell about (what IMO is) an =
academic
>>> scenario where the block solutions announcements contain *no =
information
>>> at all* about the transactions included in the blocks. Although the =
fee
>>> market would not be healthy in such a scenario, it is my feeling =
that
>>> this also requires miners to relinquish their ability to construct
>>> blocks according to their own volition (i.e., the system would =
already
>>> be centralized). I look forward to a white paper demonstrating =
otherwise!
>>>=20
>>> Best regards,
>>> Peter
>>>=20
>>>=20
>>>=20
>>> On 2015-08-29, at 2:07 PM, Matt Corallo via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org
>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>>=20
>>>> I believe it was pointed out previously in the discussion of the =
Peter R
>>>> paper, but I'll repeat it here so that its visible - this seems to
>>>> ignore the effects of transaction validation caches and block
>>>> compression protocols. Many large miners already have their own =
network
>>>> to relay blocks around the globe with only a few bytes on the wire =
at
>>>> block-time, and there is also the bitcoinrelaynetwork.org
>>>> <http://bitcoinrelaynetwork.org> network, which
>>>> does the same for smaller miners, albeit with slightly less =
efficiency.
>>>> Also, transaction validation time upon receiving a block can be =
rather
>>>> easily made negligible (ie the only validation time you should have =
is
>>>> the DB modify-utxo-set time). Thus, the increased orphan risk for
>>>> including a transaction can be reduced to a very, very tiny amount,
>>>> making the optimal blocksize, essentially, including everything =
that
>>>> you're confident is in the mempool of other reasonably large =
miners.
>>>>=20
>>>> Matt
>>>>=20
>>>> On 08/29/15 16:43, Daniele Pinna via bitcoin-dev wrote:
>>>>> I'd like to submit this paper to the dev-list which analyzes how =
miner
>>>>> advantages scale with network and mempool properties in a scenario =
of
>>>>> uncapped block sizes. The work proceeds, in a sense, from where =
Peter
>>>>> R's work left off correcting a mistake and addressing the =
critiques made
>>>>> by the community to his work.
>>>>>=20
>>>>> The main result of the work is a detailed analysis of mining =
advantages
>>>>> (defined as the added profit per unit of hash) as a function of =
miner
>>>>> hashrate. In it, I show how large block subsidies (or better, low
>>>>> mempool fees-to-subsidy ratios) incentivize the pooling of large
>>>>> hashrates due to the steady increasing of marginal profits as =
hashrates
>>>>> grow.
>>>>>=20
>>>>> The paper also shows that part of the large advantage the large =
miners
>>>>> have today is due to there being a barrier to entry into a
>>>>> high-efficiency mining class which has access to expected profits =
an
>>>>> order of magnitude larger than everyone else. As block subsidies
>>>>> decrease, this high-efficiency class is expected to vanish leading =
to a
>>>>> marginal profit structure which decreases as a function of =
hashrate.
>>>>>=20
>>>>> This work has vacuumed my entire life for the past two weeks =
leading me
>>>>> to lag behind on a lot of work. I apologize for typos which I may =
not
>>>>> have seen. I stand by for any comments the community may have and =
look
>>>>> forward to reigniting consideration of a block size scaling =
proposal
>>>>> (BIP101) which, due to the XT fork drama, I believe has been =
placed
>>>>> hastily and undeservedly on the chopping block.
>>>>>=20
>>>>> =
https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advantages-in-=
Uncapped-Block-Size-Fee-Markets
>>>>>=20
>>>>>=20
>>>>> Regards,
>>>>> Daniele
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> bitcoin-dev mailing list
>>>>> bitcoin-dev@lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>>=20
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite">Of course this assumes the network does =
not change any as a result of<br>such a system. But such a system =
provides strong incentives for the<br>network to centralize in other =
ways (<b>put all the mining nodes in one DC<br>for all miners, =
etc</b>).</blockquote><br></div><div>If all the mining nodes are in one =
data center, and if all the nodes are programmed to build blocks in =
essentially the same way, then I would agree that the orphan cost would =
be negligible! I will add this as an example of a network =
configuration where the results of my paper would be less relevant. =
</div><div><br></div><div>Peter =
</div><div><br></div><br><div><div>On 2015-08-29, at 7:35 PM, Matt =
Corallo <<a =
href=3D"mailto:lf-lists@mattcorallo.com">lf-lists@mattcorallo.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">Of course this assumes the network does not change any as =
a result of<br>such a system. But such a system provides strong =
incentives for the<br>network to centralize in other ways (put all the =
mining nodes in one DC<br>for all miners, etc).<br><br>Matt<br><br>On =
08/30/15 02:33, Matt Corallo via bitcoin-dev wrote:<br><blockquote =
type=3D"cite">It is not a purely academic scenario that blocks contain =
effectively no<br>information (that was not previously relayed). I'm not =
aware of any<br>public code to do so, but I know several large miners =
who pre-relay the<br>block(s) they are working on to other nodes of =
theirs around the globe.<br>This means at announce-time you have only a =
few bytes to broadcast (way<br>less than a packet, and effects of using =
smaller packets to relay things<br>vs larger packets are very small, if =
anything). After you've broadcast<br>to all of your nodes, hops to other =
mining nodes are probably only a<br>handful of ms away with very low =
packet loss, so relay time is no longer<br>connected to transaction =
inclusion at all (unless you're talking about<br>multi-GB blocks). Of =
course, this is relay time for large miners who can<br>invest time and =
money to build such systems. Small miners are completely<br>screwed in =
such a system.<br><br>Thus, the orphan risk for including a transaction =
is related to the<br>validation time (which is only DB modify-utxo-set =
time, essentially,<br>which maybe you can optimize much of that away, =
too, and only have to<br>pass over mempool or so). Anyway, my point, =
really, is that though<br>miners will have an incentive to not include =
transactions which will<br>trigger validation by other nodes (ie things =
not already in their<br>mempool), the incentive to not include =
transactions which have already<br>been relayed around sufficiently is, =
while not theoretically zero, as<br>near to zero in practice as you can =
get.<br><br>Matt<br><br>On 08/29/15 23:17, Peter R wrote:<br><blockquote =
type=3D"cite">Hello Matt and Daniele,<br><br><blockquote type=3D"cite"> =
this seems to ignore the effects of transaction validation caches =
and<br>*block<br>compression protocols. *<br></blockquote><br>The effect =
of block compression protocols is included. This is what I<br>call =
the "coding gain" and use the Greek letter "gamma" to represent. =
<br><br>As long as the block solution announcements contain information =
(i.e.,<br>Shannon Entropy) about the transactions included in a block, =
then the<br>fee market will be "healthy" according to the definitions =
given in the<br>linked paper (see below). This is the case right =
now, this is the case<br>with your relay network, and this would be the =
case using any<br>implementation of IBLTs that I can imagine, so long as =
miners can still<br>construct blocks according to their own volition. =
The "healthy fee<br>market" result follows from the =
Shannon-Hartley theorem; the SH-theorem<br>describes the maximum rate at =
which information (Shannon Entropy) can be<br>transmitted over a =
physical communication channel. <br><br> <a =
href=3D"https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf">https:=
//dl.dropboxusercontent.com/u/43331625/feemarket.pdf</a><br><br>I've =
exchanged emails with Greg Maxwell about (what IMO is) an =
academic<br>scenario where the block solutions announcements contain *no =
information<br>at all* about the transactions included in the blocks. =
Although the fee<br>market would not be healthy in such a =
scenario, it is my feeling that<br>this also requires miners to =
relinquish their ability to construct<br>blocks according to their own =
volition (i.e., the system would already<br>be centralized). I =
look forward to a white paper demonstrating otherwise!<br><br>Best =
regards,<br>Peter<br><br><br><br>On 2015-08-29, at 2:07 PM, Matt Corallo =
via bitcoin-dev<br><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">mailto:bitcoin-dev@l=
ists.linuxfoundation.org</a>>> wrote:<br><br><blockquote =
type=3D"cite">I believe it was pointed out previously in the discussion =
of the Peter R<br>paper, but I'll repeat it here so that its visible - =
this seems to<br>ignore the effects of transaction validation caches and =
block<br>compression protocols. Many large miners already have their own =
network<br>to relay blocks around the globe with only a few bytes on the =
wire at<br>block-time, and there is also the <a =
href=3D"http://bitcoinrelaynetwork.org">bitcoinrelaynetwork.org</a><br><=
;<a =
href=3D"http://bitcoinrelaynetwork.org">http://bitcoinrelaynetwork.org</a>=
> network, which<br>does the same for smaller miners, albeit with =
slightly less efficiency.<br>Also, transaction validation time upon =
receiving a block can be rather<br>easily made negligible (ie the only =
validation time you should have is<br>the DB modify-utxo-set time). =
Thus, the increased orphan risk for<br>including a transaction can be =
reduced to a very, very tiny amount,<br>making the optimal blocksize, =
essentially, including everything that<br>you're confident is in the =
mempool of other reasonably large miners.<br><br>Matt<br><br>On 08/29/15 =
16:43, Daniele Pinna via bitcoin-dev wrote:<br><blockquote =
type=3D"cite">I'd like to submit this paper to the dev-list which =
analyzes how miner<br>advantages scale with network and mempool =
properties in a scenario of<br>uncapped block sizes. The work proceeds, =
in a sense, from where Peter<br>R's work left off correcting a mistake =
and addressing the critiques made<br>by the community to his =
work.<br><br>The main result of the work is a detailed analysis of =
mining advantages<br>(defined as the added profit per unit of hash) as a =
function of miner<br>hashrate. In it, I show how large block subsidies =
(or better, low<br>mempool fees-to-subsidy ratios) incentivize the =
pooling of large<br>hashrates due to the steady increasing of marginal =
profits as hashrates<br>grow.<br><br>The paper also shows that part of =
the large advantage the large miners<br>have today is due to there being =
a barrier to entry into a<br>high-efficiency mining class which has =
access to expected profits an<br>order of magnitude larger than everyone =
else. As block subsidies<br>decrease, this high-efficiency class is =
expected to vanish leading to a<br>marginal profit structure which =
decreases as a function of hashrate.<br><br>This work has vacuumed my =
entire life for the past two weeks leading me<br>to lag behind on a lot =
of work. I apologize for typos which I may not<br>have seen. I stand by =
for any comments the community may have and look<br>forward to =
reigniting consideration of a block size scaling proposal<br>(BIP101) =
which, due to the XT fork drama, I believe has been placed<br>hastily =
and undeservedly on the chopping block.<br><br><a =
href=3D"https://www.scribd.com/doc/276849939/On-the-Nature-of-Miner-Advant=
ages-in-Uncapped-Block-Size-Fee-Markets">https://www.scribd.com/doc/276849=
939/On-the-Nature-of-Miner-Advantages-in-Uncapped-Block-Size-Fee-Markets</=
a><br><br><br>Regards,<br>Daniele<br><br><br>_____________________________=
__________________<br>bitcoin-dev mailing =
list<br>bitcoin-dev@lists.linuxfoundation.org<br>https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev<br><br></blockquote>________________=
_______________________________<br>bitcoin-dev mailing list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br><mailto:bitcoin-dev@lists.linuxfoundation.org&=
gt;<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<br><=
/blockquote><br></blockquote>_____________________________________________=
__<br>bitcoin-dev mailing list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br><br></blockquote></blockquote></div><br></body></html>=
--Apple-Mail=_98028B39-A9FC-4DC8-80A8-17F1FAA1DACA--
|