diff options
| author | Emin Gün Sirer <el33th4x0r@gmail.com> | 2015-12-20 00:12:49 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-12-20 05:13:10 +0000 |
| commit | 1e9ce98d5fa10a8eca89d53f5f72df5a17f60f6b (patch) | |
| tree | bc2efbc559f703e9e234a468359ee5d456cac99f | |
| parent | 02bb889d4b2dce258211e68fd7a9567ce237a138 (diff) | |
| download | pi-bitcoindev-1e9ce98d5fa10a8eca89d53f5f72df5a17f60f6b.tar.gz pi-bitcoindev-1e9ce98d5fa10a8eca89d53f5f72df5a17f60f6b.zip | |
Re: [bitcoin-dev] We need to fix the block withholding attack
| -rw-r--r-- | 0c/f50a319c861446fe1711e8a60cdff11d7804c3 | 193 |
1 files changed, 193 insertions, 0 deletions
diff --git a/0c/f50a319c861446fe1711e8a60cdff11d7804c3 b/0c/f50a319c861446fe1711e8a60cdff11d7804c3 new file mode 100644 index 000000000..6ac6109c2 --- /dev/null +++ b/0c/f50a319c861446fe1711e8a60cdff11d7804c3 @@ -0,0 +1,193 @@ +Return-Path: <el33th4x0r@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id AC67CF42 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Dec 2015 05:13:09 +0000 (UTC) +Received: by mail-qg0-f42.google.com with SMTP id 74so16117504qgh.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <aff8da46a69bdd7ef92ca87725866a5c@xbt.hk> +References: <20151219184240.GB12893@muck> + <CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com> + <219f125cee6ca68fd27016642e38fdf1@xbt.hk> + <CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com> + <aff8da46a69bdd7ef92ca87725866a5c@xbt.hk> +From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com> +Date: Sun, 20 Dec 2015 00:12:49 -0500 +Message-ID: <CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com> +To: jl2012 <jl2012@xbt.hk> +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 <bitcoin-dev@lists.linuxfoundation.org>, 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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + +<div dir=3D"ltr">There's quite a bit of confusion in this thread.<div><= +br></div><div>Peter is referring to block withholding attacks. Ittay Eyal (= +as sole=C2=A0</div><div>author -- I was not involved in this paper [1]) was= + the first=C2=A0</div><div>to analyze these attacks and to discover a fasci= +nating, paradoxical=C2=A0</div><div>result. An attacker pool (A) can take a= + certain portion of its hashpower,</div><div>use it to mine on behalf of vi= +ctim pool (B), furnish partial proofs of work</div><div>to B, but discard a= +ny full blocks it discovers. If A picks the amount of</div><div>attacking h= +ashpower judiciously, it can make more money using this</div><div>attack, t= +han it would if it were to use 100% of its hashpower for its own</div><div>= +mining. This last sentence should sound non-sensical to most of you,=C2=A0<= +/div><div>at least, it did to me. Ittay did the math, and his paper can tel= +l you=C2=A0</div><div>exactly how much of your hashpower you need to peel o= +ff and use</div><div>to attack another open pool, and you will come out ahe= +ad.=C2=A0</div><div><br></div><div>Chris Priest is confusing these attacks = +with selfish mining, and further,</div><div>his characterization of selfish= + mining is incorrect. Selfish Mining is=C2=A0</div><div>guaranteed to yield= + profits for any pool over 33% (as a result, Nick</div><div>Szabo has dubbe= +d this the "34% attack") and it may pay off even</div><div>below = +that point if the attacker is well-positioned in the network;=C2=A0</div><d= +iv>or it may not, depending on the makeup of the rest of the pools=C2=A0</d= +iv><div>as well as the network characteristics (the more centralized</div><= +div>and bigger the other pools are, the less likely it is to pay off). Ther= +e</div><div>was a lot of noise in the community when the SM paper came out,= +=C2=A0</div><div>so there are tons of incorrect response narrative out ther= +e. By now,</div><div>everyone who seems to be Bitcoin competent sees SM as = +a=C2=A0</div><div>concern, and Ethereum has already adopted our fix. I'= +d have hoped</div><div>that a poster to this list would be better informed = +than to repeat the</div><div>claim that "majority will protect Bitcoin= +" to refute a paper whose title</div><div>is "majority is not eno= +ugh."</div><div><br></div><div>Back to Ittay's paradoxical discove= +ry:</div><div><br></div><div>We have seen pool-block withholding attacks be= +fore; I believe Eligius</div><div>caught one case. I don't believe that= + any miners will deploy strong KYC</div><div>measures, and even if they did= +, I don't believe that these measures</div><div>will be effective, at l= +east, as long as the attacker is somewhat savvy.</div><div>The problem with= + these attacks are that statistics favor the attackers.</div><div>Is someon= +e really discarding the blocks they find, or are they just=C2=A0</div><div>= +unlucky? This is really hard to tell for small miners. Even with KYC,=C2=A0= +</div><div>one could break up one's servers, register them under differ= +ent=C2=A0</div><div>people's names, and tunnel them through VPNs.</div>= +<div><br></div><div>Keep in mind that when an open pool gets big, like GHas= +h did and=C2=A0<br></div><div>two other pools did before them, the only thi= +ng at our disposal used</div><div>to be to yell at people about centralizat= +ion until they left the big</div><div>pools and reformed into smaller group= +s. Not only was such yelling</div><div>kind of desperate looking, it wasn&#= +39;t incredibly effective, either.=C2=A0</div><div>We had no protocol mecha= +nisms that put pressure on big pools to=C2=A0</div><div>stop signing up peo= +ple. Ittay's discovery changed that: pools that=C2=A0</div><div>get to = +be very big by indiscriminately signing up miners are likely to</div><div>b= +e infiltrated and their profitability will drop. And Peter's post is=C2= +=A0</div><div>evidence that this is, indeed, happening as predicted. This i= +s a</div><div>good outcome, it puts pressure on the big pools to not grow.= +=C2=A0</div><div><br></div><div>Peter, you allude to a specific suggestion = +from Luke-Jr. Can you=C2=A0</div><div>please describe what it is?=C2=A0</di= +v><div><br></div><div>Hope this is useful,</div><div>- egs</div><div><br></= +div><div>[1]=C2=A0<a href=3D"https://www.cs.cornell.edu/~ie53/publications/= +btcPoolsSP15.pdf">https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP1= +5.pdf</a></div><div><br></div></div> + +--001a11355b16a2eecf05274d6d94-- + |