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
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <andreas@antonopoulos.com>) id 1VesPG-0001yw-JC
for Bitcoin-development@lists.sourceforge.net;
Fri, 08 Nov 2013 20:11:50 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of
antonopoulos.com designates 209.85.214.174 as permitted sender)
client-ip=209.85.214.174; envelope-from=andreas@antonopoulos.com;
helo=mail-ob0-f174.google.com;
Received: from mail-ob0-f174.google.com ([209.85.214.174])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VesPE-0007In-SY
for Bitcoin-development@lists.sourceforge.net;
Fri, 08 Nov 2013 20:11:50 +0000
Received: by mail-ob0-f174.google.com with SMTP id vb8so1947647obc.19
for <Bitcoin-development@lists.sourceforge.net>;
Fri, 08 Nov 2013 12:11:43 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=oCxM/sJUCHhMVVOe8uCd7y7tUlOdcfTT4SGGyLg5+cM=;
b=I9Jr3WzJdPoaVTHJZMypBBe1Xtxlf4UnNcMwOxR3m0q8oFmN13LGkfRIzsP3lW3wN+
3mj6zgXYMQt2TX9u4bNirDtyLmbX2tzu8627CWRpRvktjlh5iELM7ynFND7N3Y8fjvBQ
diS2MisIazz5XpndHKVjmZxl4VKhtzbDGdkU00aqOwN0yCCDBUtLoczzvnIqEiW4lp54
E1m/KdiKhiGAvFvtwYkK4TCSp0qU6Jv6usQxCE9eqEySxnQc99Ho0QH0ney4xnfkHEA2
ctCFbqGaHK1UauVljty/DANTngo0yyvRQGSqM9cd795RjrXDhDCzGJ7d5pZ6cyqp/qWM
9i3Q==
X-Gm-Message-State: ALoCoQkP6MIUmVa1GmuJ9ONyTr0eg/p2YLoXzx79ZCDLkoohPR2CFjmjuVhya7ZdP8kt5PvDhDje
MIME-Version: 1.0
X-Received: by 10.182.28.134 with SMTP id b6mr6480693obh.27.1383940151111;
Fri, 08 Nov 2013 11:49:11 -0800 (PST)
Sender: andreas@antonopoulos.com
Received: by 10.182.231.163 with HTTP; Fri, 8 Nov 2013 11:49:11 -0800 (PST)
In-Reply-To: <CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
References: <5279D49D.5050807@jerviss.org>
<CAJHLa0N1-8LfFuWq=vS0r-t2Bt-qZ6yKuGjrnicUOj+K6Gpx5A@mail.gmail.com>
<CANOOu=-MsPPgACKcHvsvtFAOAiULL+BOQvJz1tC3L=nT8wN01Q@mail.gmail.com>
<20131107034404.GA5140@savin>
<CABsx9T35Po7pUb2sr15zD5WODYqR4-xNvJD0Jz5+Of3d-NjPdg@mail.gmail.com>
<20131107132442.GB22476@savin>
<CANEZrP3T4qsz8qqPxqtP5oXNYA_WT5OQPrC2uAKuQyDqJ0N9Rw@mail.gmail.com>
<CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
Date: Fri, 8 Nov 2013 11:49:11 -0800
X-Google-Sender-Auth: cbYxdAcNjw3vh8bdJ99sNC7K0E4
Message-ID: <CAFmyj8y2H8hR=T4Ogui09MPOzz1nydNDvNZug2GZ8bWiu+52wA@mail.gmail.com>
From: "Andreas M. Antonopoulos" <andreas@rooteleven.com>
To: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a11c2903c19077104eaafadb3
X-Spam-Score: -0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: doubleclick.net]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
X-Headers-End: 1VesPE-0007In-SY
Subject: Re: [Bitcoin-development] we can all relax now
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2013 20:11:50 -0000
--001a11c2903c19077104eaafadb3
Content-Type: text/plain; charset=ISO-8859-1
Nicholas Weaver is reporting that pools have already started delaying
blocks, something that hints at Selfish Mining, since Nov. 3rd.
https://medium.com/something-like-falling/d321a2ef9317
He dismisses other reasons for delayed block propagation.
Any ideas on whether pools are already mucking around with block delaying
tactics?
I have no idea if this report is accurate or explained by some other issue
in the network, does anyone here have a comment on this?
On Thu, Nov 7, 2013 at 10:28 AM, Daniel Lidstrom <lidstrom83@gmail.com>wrote:
> Hey Peter, something seems wrong with your above analysis: I think a miner
> would withhold his block not because it leads to a greater probability of
> winning the next one, but because it increases his expected revenue.
>
> Suppose a cabal with fraction q of the total hashing power is n blocks
> ahead on a secret branch of that has mined r_tot coins, and let r_next be
> its next block's reward. If the cabal chooses not to broadcast its secret
> chain until at least the next block, its expected revenue after the next
> block is found is
>
> (1 - (1-q)^(n+1))*(r_tot + r_next)
>
> If it does broadcast, its expected revenue after the next block is found is
>
> r_tot + q * r_next
>
> If the cabal seeks only to maximize immediate revenue, then after a bit of
> algebra we find that it will withhold its chain if
>
> q > 1 - ( 1 + r_tot / r_next )^(-1/n)
>
> So if the cabal has just mined his first block off of the public chain,
> i.e. n = 1, and if the block reward is relatively stable, i.e. r_next =
> r_tot, then it needs q > 50% to profitably withhold, not the 29.2% you
> calculated.
>
> From this formula we can also see that if the miner wins the race and
> withholds again, then he must grow q to compensate for the increase in
> r_tot, and any decrease in n. So generally publication becomes
> increasingly in the cabal's interest, and secret chains will tend not to
> grow too large (intuition tells me that simulations using the above formula
> should bear this out).
>
> This seem correct to you?
>
>
> On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <mike@plan99.net> wrote:
>
>> Once the ASIC race calms down because everyone has one, has more or less
>> optimal power supplies, process improvements aren't easily reachable
>> anymore etc then I'd expect people to dissipate from the large pools
>> because eliminating their fees will become the next lowest hanging fruit to
>> squeeze out extra profit. There's no particular reason we need only a
>> handful of pools that control a major fraction of the hashpower.
>>
>> If we end up with a few hundred pools or lots of miners on p2pool, then a
>> lot of these theoretical attacks become not very relevant (I don't think ID
>> sacrifices will be so common or large as to justify a pile of custom mining
>> code+strategies at any point ...)
>>
>>
>> On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <pete@petertodd.org> wrote:
>>
>>> On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
>>> > > P.S: If any large pools want to try this stuff out, give me a shout.
>>> You
>>> > > have my PGP key - confidentiality assured.
>>> > >
>>> >
>>> > If I find out one of the large pools decides to run this 'experiment'
>>> on
>>> > the main network, I will make it my mission to tell people to switch
>>> to a
>>> > more responsible pool.
>>>
>>> I hope they listen.
>>>
>>> A few months ago ASICMiner could have made use of that attack if my
>>> memories of their peak hashing power were correct. They certainely could
>>> have used the selfish miner version, (we need better name for that)
>>> although development costs would eat into profits.
>>>
>>> GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool" - dunno
>>> what they mean by that, but they're involved with CEX.IO who has
>>> physical control of a bunch of hashing power so I guess that means their
>>> model is like ASICMiners. They're a bit short of 30%, but maybe some
>>> behind-the-scenes deals would fix that, and/or lowering the barrier with
>>> reactive block publishing. (a better name)
>>>
>>> > And if you think you can get away with driving up EVERYBODY's orphan
>>> rate
>>> > without anybody noticing, you should think again.
>>>
>>> ...and remember, if you only do the attack a little bit, you still can
>>> earn more profit, and only drive up the orphan rate a little bit. So who
>>> knows, maybe the orphans are real, or maybe they're an attack? ASICMiner
>>> was involved with a bunch of orphans a while back...
>>>
>>> You know what this calls for? A witchhunt!
>>>
>>> BURN THE LARGE POOLS!
>>>
>>> > > P.P.S: If you're mining on a pool with more than, like, 1% hashing
>>> > > power, do the math on varience... Seriously, stop it and go mine on a
>>> > > smaller pool, or better yet, p2pool.
>>> > >
>>> >
>>> > That I agree with.
>>>
>>> Glad to hear.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> November Webinars for C, C++, Fortran Developers
>>> Accelerate application performance with scalable programming models.
>>> Explore
>>> techniques for threading, error checking, porting, and tuning. Get the
>>> most
>>> from the latest Intel processors and coprocessors. See abstracts and
>>> register
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> November Webinars for C, C++, Fortran Developers
>> Accelerate application performance with scalable programming models.
>> Explore
>> techniques for threading, error checking, porting, and tuning. Get the
>> most
>> from the latest Intel processors and coprocessors. See abstracts and
>> register
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--001a11c2903c19077104eaafadb3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>Nicholas Weaver is reporting that pools have alr=
eady started delaying blocks, something that hints at Selfish Mining, since=
Nov. 3rd.<br><a href=3D"https://medium.com/something-like-falling/d321a2ef=
9317">https://medium.com/something-like-falling/d321a2ef9317</a><br>
<br></div>He dismisses other reasons for delayed block propagation. <br><br=
>Any ideas on whether pools are already mucking around with block delaying =
tactics? <br><br></div>I have no idea if this report is accurate or explain=
ed by some other issue in the network, does anyone here have a comment on t=
his?<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
Nov 7, 2013 at 10:28 AM, Daniel Lidstrom <span dir=3D"ltr"><<a href=3D"=
mailto:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div>Hey Peter, s=
omething seems wrong with your above=20
analysis: I think a miner would withhold his block not because it leads
to a greater probability of winning the next one, but because it=20
increases his expected revenue.<br>
<br>Suppose a cabal with fraction q of the total hashing power is n=20
blocks ahead on a secret branch of that has mined r_tot coins, and let=20
r_next be its next block's reward.=A0 If the cabal chooses not to=20
broadcast its secret chain until at least the next block, its expected=20
revenue after the next block is found is<br>
<br>(1 - (1-q)^(n+1))*(r_tot + r_next)<br><br>If it does broadcast, its exp=
ected revenue after the next block is found is<br><br>r_tot + q * r_next</d=
iv><div><br>If
the cabal seeks only to maximize immediate revenue, then after a bit of al=
gebra we find
that it will withhold its chain if<br>
<br>q > 1 - ( 1 + r_tot / r_next )^(-1/n)<br><br></div><div>So if the ca=
bal has just mined his first block off of the public chain, i.e. n =3D 1, a=
nd if the block reward is relatively stable, i.e. r_next =3D r_tot, then it=
needs q > 50% to profitably withhold, not the 29.2% you calculated.<br>
<br></div><div>From this formula we can also see that if the miner wins the=
race and withholds again, then he must grow q to compensate for the increa=
se in r_tot, and any decrease in n.=A0 So generally publication becomes inc=
reasingly in the cabal's interest, and secret chains will tend not to g=
row too large (intuition tells me that simulations using the above formula =
should bear this out).<br>
<br></div><div>This seem correct to you?<br></div></div></div></div><div cl=
ass=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div cl=
ass=3D"gmail_quote">On Thu, Nov 7, 2013 at 9:14 AM, Mike Hearn <span dir=3D=
"ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.=
net</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Once the ASIC race calms do=
wn because everyone has one, has more or less optimal power supplies, proce=
ss improvements aren't easily reachable anymore etc then I'd expect=
people to dissipate from the large pools because eliminating their fees wi=
ll become the next lowest hanging fruit to squeeze out extra profit. There&=
#39;s no particular reason we need only a handful of pools that control a m=
ajor fraction of the hashpower.=A0<div>
<br></div><div>If we end up with a few hundred pools or lots of miners on p=
2pool, then a lot of these theoretical attacks become not very relevant (I =
don't think ID sacrifices will be so common or large as to justify a pi=
le of custom mining code+strategies at any point ...)</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"><div><d=
iv>On Thu, Nov 7, 2013 at 2:24 PM, Peter Todd <span dir=3D"ltr"><<a href=
=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>>=
</span> wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div><div>On Thu, Nov 07, 2=
013 at 02:56:56PM +1000, Gavin Andresen wrote:<br>
> > P.S: If any large pools want to try this stuff out, give me a sho=
ut. You<br>
> > have my PGP key - confidentiality assured.<br>
> ><br>
><br>
> If I find out one of the large pools decides to run this 'experime=
nt' on<br>
> the main network, I will make it my mission to tell people to switch t=
o a<br>
> more responsible pool.<br>
<br>
</div>I hope they listen.<br>
<br>
A few months ago ASICMiner could have made use of that attack if my<br>
memories of their peak hashing power were correct. They certainely could<br=
>
have used the selfish miner version, (we need better name for that)<br>
although development costs would eat into profits.<br>
<br>
GHash.IO, 22%, says they're a "private Bitfury ASIC mining pool&qu=
ot; - dunno<br>
what they mean by that, but they're involved with <a href=3D"http://CEX=
.IO" target=3D"_blank">CEX.IO</a> who has<br>
physical control of a bunch of hashing power so I guess that means their<br=
>
model is like ASICMiners. They're a bit short of 30%, but maybe some<br=
>
behind-the-scenes deals would fix that, and/or lowering the barrier with<br=
>
reactive block publishing. (a better name)<br>
<div><br>
> And if you think you can get away with driving up EVERYBODY's orph=
an rate<br>
> without anybody noticing, you should think again.<br>
<br>
</div>...and remember, if you only do the attack a little bit, you still ca=
n<br>
earn more profit, and only drive up the orphan rate a little bit. So who<br=
>
knows, maybe the orphans are real, or maybe they're an attack? ASICMine=
r<br>
was involved with a bunch of orphans a while back...<br>
<br>
You know what this calls for? A witchhunt!<br>
<br>
BURN THE LARGE POOLS!<br>
<div><br>
> > P.P.S: If you're mining on a pool with more than, like, 1% ha=
shing<br>
> > power, do the math on varience... Seriously, stop it and go mine =
on a<br>
> > smaller pool, or better yet, p2pool.<br>
> ><br>
><br>
> That I agree with.<br>
<br>
</div>Glad to hear.<br>
<span><font color=3D"#888888"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
0000000000000007bd936f19e33bc8b8f9bb1f4c013b863ef60a7f5a6a5d2112<br>
</font></span><br></div></div><div>----------------------------------------=
--------------------------------------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></div></blockquote></div><br></div>
<br>-----------------------------------------------------------------------=
-------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
November Webinars for C, C++, Fortran Developers<br>
Accelerate application performance with scalable programming models. Explor=
e<br>
techniques for threading, error checking, porting, and tuning. Get the most=
<br>
from the latest Intel processors and coprocessors. See abstracts and regist=
er<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D60136231&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&iu=3D/4140/ostg.clktrk</a><br>___________________=
____________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>
--001a11c2903c19077104eaafadb3--
|