From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VdpRb-0003UZ-Np for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 22:49:55 +0000 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; Received: from mail-lb0-f179.google.com ([209.85.217.179]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VdpRZ-0007AO-Gi for bitcoin-development@lists.sourceforge.net; Tue, 05 Nov 2013 22:49:55 +0000 Received: by mail-lb0-f179.google.com with SMTP id w6so7201678lbh.10 for ; Tue, 05 Nov 2013 14:49:46 -0800 (PST) X-Received: by 10.152.28.105 with SMTP id a9mr3098145lah.41.1383691786760; Tue, 05 Nov 2013 14:49:46 -0800 (PST) MIME-Version: 1.0 Sender: stanga@gmail.com Received: by 10.112.105.35 with HTTP; Tue, 5 Nov 2013 14:49:26 -0800 (PST) In-Reply-To: References: <20131105170541.GA13660@petertodd.org> From: Ittay Date: Tue, 5 Nov 2013 17:49:26 -0500 X-Google-Sender-Auth: LBKqMua00DxtH_gXI5Rau4lwxo0 Message-ID: To: Jeremy Spilman Content-Type: multipart/alternative; boundary=089e0160a2406db69204ea75d96c X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -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 (stanga[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: ethz.ch] 1.0 HTML_MESSAGE BODY: HTML included in message 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: 1VdpRZ-0007AO-Gi Cc: Ittay , Gavin Andresen , =?ISO-8859-1?Q?Emin_G=FCn_Sirer?= , Bitcoin Dev Subject: Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold. X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:49:55 -0000 --089e0160a2406db69204ea75d96c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman 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



On Tue, Nov 5, 2013 at 1:57 PM, Jeremy Spilman &l= t;jeremy@taplink.co<= /a>> wrote:
=A0
I think it's a stre= tch to say 'y' is 0 with good connectivity. Even the best connected= mining pools today are concerned with this 'y' factor.=A0

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

Here's a probably very dumb idea... to throw o= ut 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 pr= ivate chains?

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's the cat= ch - maybe the decryption results in junk, maybe it results a new longer bl= ock. If it'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' can't race the network anymore, because they are a= lways 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&#= 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.

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

Best,=A0
Ittay=A0

--089e0160a2406db69204ea75d96c--