path: root/81/0ef9164bdd56e798440a56449f97411522374f

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">&lt;<a href=3D"=
mailto:lidstrom83@gmail.com" target=3D"_blank">lidstrom83@gmail.com</a>&gt;=
</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&#39;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 &gt; 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 &gt; 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&#39;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">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.=
net</a>&gt;</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&#39;t easily reachable anymore etc then I&#39;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&#39;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">&lt;<a href=
=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;=
</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>
&gt; &gt; P.S: If any large pools want to try this stuff out, give me a sho=
ut. You<br>
&gt; &gt; have my PGP key - confidentiality assured.<br>
&gt; &gt;<br>
&gt;<br>
&gt; If I find out one of the large pools decides to run this &#39;experime=
nt&#39; on<br>
&gt; the main network, I will make it my mission to tell people to switch t=
o a<br>
&gt; 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&#39;re a &quot;private Bitfury ASIC mining pool&qu=
ot; - dunno<br>
what they mean by that, but they&#39;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&#39;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>
&gt; And if you think you can get away with driving up EVERYBODY&#39;s orph=
an rate<br>
&gt; 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&#39;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>
&gt; &gt; P.P.S: If you&#39;re mining on a pool with more than, like, 1% ha=
shing<br>
&gt; &gt; power, do the math on varience... Seriously, stop it and go mine =
on a<br>
&gt; &gt; smaller pool, or better yet, p2pool.<br>
&gt; &gt;<br>
&gt;<br>
&gt; That I agree with.<br>
<br>
</div>Glad to hear.<br>
<span><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;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&amp;iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D60136231&amp;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--