path: root/b0/e1ba464f5370d9630117e52a20900d722a4cd9

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 <lidstrom83@gmail.com>) id 1VeUKD-0000Dm-EJ
	for Bitcoin-development@lists.sourceforge.net;
	Thu, 07 Nov 2013 18:29:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.174 as permitted sender)
	client-ip=209.85.223.174; envelope-from=lidstrom83@gmail.com;
	helo=mail-ie0-f174.google.com; 
Received: from mail-ie0-f174.google.com ([209.85.223.174])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1VeUKB-0003iS-Kk
	for Bitcoin-development@lists.sourceforge.net;
	Thu, 07 Nov 2013 18:29:01 +0000
Received: by mail-ie0-f174.google.com with SMTP id qd12so1464719ieb.5
	for <Bitcoin-development@lists.sourceforge.net>;
	Thu, 07 Nov 2013 10:28:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.119.161 with SMTP id kv1mr2959533igb.51.1383848933020;
	Thu, 07 Nov 2013 10:28:53 -0800 (PST)
Received: by 10.64.81.230 with HTTP; Thu, 7 Nov 2013 10:28:52 -0800 (PST)
In-Reply-To: <CANEZrP3T4qsz8qqPxqtP5oXNYA_WT5OQPrC2uAKuQyDqJ0N9Rw@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>
Date: Thu, 7 Nov 2013 11:28:52 -0700
Message-ID: <CADjHg8GNuoPQ7Ama0A=iGmboeE_T5LrLRHPKyvQqWwKAjT3K3w@mail.gmail.com>
From: Daniel Lidstrom <lidstrom83@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=001a1134421613bbcc04ea9a7006
X-Spam-Score: -0.3 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(lidstrom83[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
	digit (lidstrom83[at]gmail.com)
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VeUKB-0003iS-Kk
Cc: Bitcoin Dev <Bitcoin-development@lists.sourceforge.net>, webmaster@ghash.io,
	webmaster@cex.io
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: Thu, 07 Nov 2013 18:29:01 -0000

--001a1134421613bbcc04ea9a7006
Content-Type: text/plain; charset=ISO-8859-1

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
>
>

--001a1134421613bbcc04ea9a7006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hey Peter, something 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"gmail_extra"><br><br><div class=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 class=3D"h5">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@petertod=
d.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 class=3D"h5"><div>On T=
hu, Nov 07, 2013 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 class=3D"im">---------------------------=
---------------------------------------------------<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">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>

--001a1134421613bbcc04ea9a7006--