From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AC67CF42 for ; Sun, 20 Dec 2015 05:13:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f42.google.com (mail-qg0-f42.google.com [209.85.192.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3BD6ED for ; Sun, 20 Dec 2015 05:13:09 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id 74so16117504qgh.1 for ; Sat, 19 Dec 2015 21:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cp10Uuvx62H9lLenQBxSn41HYbrA2J0zG1aGwHkmazs=; b=nAG2eWy4Pe1pILzFEwKmwfelwByKBrfvzW9Hqp+HQpiCgAgdfcew7xjsSxshd88Jxd z71+OeUXRry7T8Zx4Y4lJnmgKLXal4t9nvlw9O90dM+lvkUYLuPEt7fgBwZUCGc1iTRR U/TeXn+mwsbVe5MzWNLQ3UDUOexY5rH1m93X3J2HFDZgxU5QKTWRcvjPnYo+k8wyJoP0 bSQEmSBd+U2owsjab4sRSS1XztOPsS1j7hiagg3/xOcboCPjMAimIyxHUYWGHYkPoRqo NYv83W2MkbJjKeEoialmAifZcV29wyvXt84JI9OBv5beKawFfLR0Mp8YsV932lPr3kXY VXkA== X-Received: by 10.140.19.229 with SMTP id 92mr16233053qgh.100.1450588388910; Sat, 19 Dec 2015 21:13:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.29.73 with HTTP; Sat, 19 Dec 2015 21:12:49 -0800 (PST) In-Reply-To: References: <20151219184240.GB12893@muck> <219f125cee6ca68fd27016642e38fdf1@xbt.hk> From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= Date: Sun, 20 Dec 2015 00:12:49 -0500 Message-ID: To: jl2012 Content-Type: multipart/alternative; boundary=001a11355b16a2eecf05274d6d94 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 20 Dec 2015 08:15:23 +0000 Cc: Bitcoin Dev , nbvfour@gmail.com Subject: Re: [bitcoin-dev] We need to fix the block withholding attack X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 05:13:10 -0000 --001a11355b16a2eecf05274d6d94 Content-Type: text/plain; charset=UTF-8 There's quite a bit of confusion in this thread. Peter is referring to block withholding attacks. Ittay Eyal (as sole author -- I was not involved in this paper [1]) was the first to analyze these attacks and to discover a fascinating, paradoxical result. An attacker pool (A) can take a certain portion of its hashpower, use it to mine on behalf of victim pool (B), furnish partial proofs of work to B, but discard any full blocks it discovers. If A picks the amount of attacking hashpower judiciously, it can make more money using this attack, than it would if it were to use 100% of its hashpower for its own mining. This last sentence should sound non-sensical to most of you, at least, it did to me. Ittay did the math, and his paper can tell you exactly how much of your hashpower you need to peel off and use to attack another open pool, and you will come out ahead. Chris Priest is confusing these attacks with selfish mining, and further, his characterization of selfish mining is incorrect. Selfish Mining is guaranteed to yield profits for any pool over 33% (as a result, Nick Szabo has dubbed this the "34% attack") and it may pay off even below that point if the attacker is well-positioned in the network; or it may not, depending on the makeup of the rest of the pools as well as the network characteristics (the more centralized and bigger the other pools are, the less likely it is to pay off). There was a lot of noise in the community when the SM paper came out, so there are tons of incorrect response narrative out there. By now, everyone who seems to be Bitcoin competent sees SM as a concern, and Ethereum has already adopted our fix. I'd have hoped that a poster to this list would be better informed than to repeat the claim that "majority will protect Bitcoin" to refute a paper whose title is "majority is not enough." Back to Ittay's paradoxical discovery: We have seen pool-block withholding attacks before; I believe Eligius caught one case. I don't believe that any miners will deploy strong KYC measures, and even if they did, I don't believe that these measures will be effective, at least, as long as the attacker is somewhat savvy. The problem with these attacks are that statistics favor the attackers. Is someone really discarding the blocks they find, or are they just unlucky? This is really hard to tell for small miners. Even with KYC, one could break up one's servers, register them under different people's names, and tunnel them through VPNs. Keep in mind that when an open pool gets big, like GHash did and two other pools did before them, the only thing at our disposal used to be to yell at people about centralization until they left the big pools and reformed into smaller groups. Not only was such yelling kind of desperate looking, it wasn't incredibly effective, either. We had no protocol mechanisms that put pressure on big pools to stop signing up people. Ittay's discovery changed that: pools that get to be very big by indiscriminately signing up miners are likely to be infiltrated and their profitability will drop. And Peter's post is evidence that this is, indeed, happening as predicted. This is a good outcome, it puts pressure on the big pools to not grow. Peter, you allude to a specific suggestion from Luke-Jr. Can you please describe what it is? Hope this is useful, - egs [1] https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf --001a11355b16a2eecf05274d6d94 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's quite a bit of confusion in this thread.
<= br>
Peter is referring to block withholding attacks. Ittay Eyal (= as sole=C2=A0
author -- I was not involved in this paper [1]) was= the first=C2=A0
to analyze these attacks and to discover a fasci= nating, paradoxical=C2=A0
result. An attacker pool (A) can take a= certain portion of its hashpower,
use it to mine on behalf of vi= ctim pool (B), furnish partial proofs of work
to B, but discard a= ny full blocks it discovers. If A picks the amount of
attacking h= ashpower judiciously, it can make more money using this
attack, t= han it would if it were to use 100% of its hashpower for its own
= mining. This last sentence should sound non-sensical to most of you,=C2=A0<= /div>
at least, it did to me. Ittay did the math, and his paper can tel= l you=C2=A0
exactly how much of your hashpower you need to peel o= ff and use
to attack another open pool, and you will come out ahe= ad.=C2=A0

Chris Priest is confusing these attacks = with selfish mining, and further,
his characterization of selfish= mining is incorrect. Selfish Mining is=C2=A0
guaranteed to yield= profits for any pool over 33% (as a result, Nick
Szabo has dubbe= d this the "34% attack") and it may pay off even
below = that point if the attacker is well-positioned in the network;=C2=A0
or it may not, depending on the makeup of the rest of the pools=C2=A0
as well as the network characteristics (the more centralized
<= div>and bigger the other pools are, the less likely it is to pay off). Ther= e
was a lot of noise in the community when the SM paper came out,= =C2=A0
so there are tons of incorrect response narrative out ther= e. By now,
everyone who seems to be Bitcoin competent sees SM as = a=C2=A0
concern, and Ethereum has already adopted our fix. I'= d have hoped
that a poster to this list would be better informed = than to repeat the
claim that "majority will protect Bitcoin= " to refute a paper whose title
is "majority is not eno= ugh."

Back to Ittay's paradoxical discove= ry:

We have seen pool-block withholding attacks be= fore; I believe Eligius
caught one case. I don't believe that= any miners will deploy strong KYC
measures, and even if they did= , I don't believe that these measures
will be effective, at l= east, as long as the attacker is somewhat savvy.
The problem with= these attacks are that statistics favor the attackers.
Is someon= e really discarding the blocks they find, or are they just=C2=A0
= unlucky? This is really hard to tell for small miners. Even with KYC,=C2=A0=
one could break up one's servers, register them under differ= ent=C2=A0
people's names, and tunnel them through VPNs.
=

Keep in mind that when an open pool gets big, like GHas= h did and=C2=A0
two other pools did before them, the only thi= ng at our disposal used
to be to yell at people about centralizat= ion until they left the big
pools and reformed into smaller group= s. Not only was such yelling
kind of desperate looking, it wasn&#= 39;t incredibly effective, either.=C2=A0
We had no protocol mecha= nisms that put pressure on big pools to=C2=A0
stop signing up peo= ple. Ittay's discovery changed that: pools that=C2=A0
get to = be very big by indiscriminately signing up miners are likely to
b= e infiltrated and their profitability will drop. And Peter's post is=C2= =A0
evidence that this is, indeed, happening as predicted. This i= s a
good outcome, it puts pressure on the big pools to not grow.= =C2=A0

Peter, you allude to a specific suggestion = from Luke-Jr. Can you=C2=A0
please describe what it is?=C2=A0

Hope this is useful,
- egs
--001a11355b16a2eecf05274d6d94--