1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
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--
|
