Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.179 as permitted sender)
	client-ip=209.85.217.179; envelope-from=stanga@gmail.com;
	helo=mail-lb0-f179.google.com; 
MIME-Version: 1.0
Sender: stanga@gmail.com
In-Reply-To: <op.w53ax8dtyldrnw@laptop-air>
References: <CABT1wWkOukEzxK5fLbnA4ZgJGN1hb_DMteCJOfA13FE_QZCi=Q@mail.gmail.com>
	<20131105170541.GA13660@petertodd.org>
	<CABT1wWnPJOKKT5v2hGePkUT8jNau=TEK5s-n2so2kQKnv-HfqQ@mail.gmail.com>
	<op.w53ax8dtyldrnw@laptop-air>
From: Ittay <ittay.eyal@cornell.edu>
Date: Tue, 5 Nov 2013 17:49:26 -0500
Message-ID: <CABT1wW=cKEA+TU5+n1n0cqvqwx8oWgpUXRmGJQCNLfQehxs6bQ@mail.gmail.com>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=089e0160a2406db69204ea75d96c
Cc: Ittay <ittay.eyal@cornell.edu>,
	Gavin Andresen <gavin@bitcoinfoundation.org>,
	=?ISO-8859-1?Q?Emin_G=FCn_Sirer?= <egs@systems.cs.cornell.edu>,
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish
 mining threshold.
Precedence: list

--089e0160a2406db69204ea75d96c
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <jeremy@taplink.co> wrote:


> I think it's a stretch to say 'y' is 0 with good connectivity. Even the
> best connected mining pools today are concerned with this 'y' factor.
>

Check out the following paper for the effect a single node can have on
propagation, and on the relation between block size and propagation speed.
This strongly supports our assumption.
http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf


>
> Here's a probably very dumb idea... to throw out one possible "solution"...
>
> You want a way to fake-out the 'selfish miner' into disclosing their
> blocks -- how can your force their hand to prevent them from accumulating
> longer private chains?
>
> What if you propagate (and relay) an encrypted block header which honest
> miners will timestamp when they receive it, then 10 seconds later propagate
> the decryption key to unblind it. But here's the catch - maybe the
> decryption results in junk, maybe it results a new longer block. If it's a
> real block then it gets priority based on when the ciphertext was received
> instead of when the decryption key was received. Now 'selfish miner' can't
> race the network anymore, because they are always in state 0' and can't
> tell if they are up against a ghost, or a real competing block. If they
> wait for the decryption key to check, it's too late, and they are
> guaranteed to lose unless they can out-race the network, e.g. back at
> t=50%. Of course there would need to be some way to anti-DDoS this which
> allows for some amount of these fake-outs without letting them get out of
> hand.
>

That's a dangerous way to go, opening the door to DoS attacks, as you
mention. Besides, it makes a simple algorithm complicated, and doing such
changes may lead to different vulnerabilities that are difficult to cover.

Best,
Ittay

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jeremy@taplink.co" target=3D"_blank">jeremy@taplink.co<=
/a>&gt;</span> wrote:<br>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div><div></div><div>I think it&#39;s a stre=
tch to say &#39;y&#39; is 0 with good connectivity. Even the best connected=
 mining pools today are concerned with this &#39;y&#39; factor.=A0</div>

</div></blockquote><div><br></div><div>Check out the following paper for th=
e effect a single node can have on propagation, and on the relation between=
 block size and propagation speed. This strongly supports our assumption.=
=A0</div>

<div><a href=3D"http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b2=
3fc0/P2P2013_041.pdf">http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7f=
da78b23fc0/P2P2013_041.pdf</a><br></div><div>=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><div><br></div><div>Here&#39;s a probably very dumb idea... to throw o=
ut one possible &quot;solution&quot;...</div><div><br></div><div>You want a=
 way to fake-out the &#39;selfish miner&#39; into disclosing their blocks -=
- how can your force their hand to prevent them from accumulating longer pr=
ivate chains?</div>

<div><br></div><div>What if you propagate (and relay) an encrypted block he=
ader which honest miners will timestamp when they receive it, then 10 secon=
ds later propagate the decryption key to unblind it. But here&#39;s the cat=
ch - maybe the decryption results in junk, maybe it results a new longer bl=
ock. If it&#39;s a real block then it gets priority based on when the ciphe=
rtext was received instead of when the decryption key was received. Now =
9;selfish miner&#39; can&#39;t race the network anymore, because they are a=
lways in state 0&#39; and can&#39;t tell if they are up against a ghost, or=
 a real competing block. If they wait for the decryption key to check, it&#=
39;s too late, and they are guaranteed to lose unless they can out-race the=
 network, e.g. back at t=3D50%. Of course there would need to be some way t=
o anti-DDoS this which allows for some amount of these fake-outs without le=
tting them get out of hand.</div>

</div></blockquote><div><br></div><div>That&#39;s a dangerous way to go, op=
ening the door to DoS attacks, as you mention. Besides, it makes a simple a=
lgorithm complicated, and doing such changes may lead to different vulnerab=
ilities that are difficult to cover.=A0</div>

<div></div></div><br></div><div class=3D"gmail_extra">Best,=A0</div><div cl=
ass=3D"gmail_extra">Ittay=A0</div><div class=3D"gmail_extra"><br></div></di=
v>

--089e0160a2406db69204ea75d96c--