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
|
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 E6D111067
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Dec 2015 19:30:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com
[209.85.220.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0B10013D
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Dec 2015 19:30:34 +0000 (UTC)
Received: by mail-qk0-f171.google.com with SMTP id n135so78054687qka.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 28 Dec 2015 11:30:34 -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
:content-type; bh=7cfd6T0dBX6qLqmYXBgJ0V2zLn7j+KQmf9tD1d1VfJs=;
b=CPue2fbjmG4eiEmpe6vKjGw00Mrj+PS9G15WIWsJTdGSbQzMQ96/8R21CQShOsdgzJ
IPY5sItyHTlBmSRai2a4mHIuWFvK8WGS85FKttPokLz0bInejgtFrIj3RPAcVj3HJMMw
jcvNKw2ZigPh0qTvMdIPtNnKcVWRB2qaiZB9cZuJ05iS2qDs/dFO1JOrZYRm9VH8YXq9
MvX9VnVSSttNYF9QwaecwU2qnceG+XaLpKbJNgaLfELdQYwmxjK9frZHDpgLRm20xjgS
+23wsFc3hPKobOUI92PuovoyR93OOAcAzmRjmKUmMvsxWsMCvBnGGG8Axw5SLV/qqNVw
N8wA==
X-Received: by 10.55.78.207 with SMTP id c198mr72084997qkb.34.1451331034207;
Mon, 28 Dec 2015 11:30:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.29.73 with HTTP; Mon, 28 Dec 2015 11:30:14 -0800 (PST)
In-Reply-To: <20151228191228.GC12298@muck>
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<4882BD35-D890-4860-9222-5C23AEB6AE89@mattcorallo.com>
<CAAcC9yspsPs3gbumS4rTOg-P-=V=tycn2Z1nVPGGHwJ-nP+PBg@mail.gmail.com>
<20151220044450.GA23942@muck>
<CAP3QyGJD3SaM6Bvvw66jAvVFkQhrfJfRQTxbbe8a=O1zK_P6tw@mail.gmail.com>
<20151228191228.GC12298@muck>
From: =?UTF-8?Q?Emin_G=C3=BCn_Sirer?= <el33th4x0r@gmail.com>
Date: Mon, 28 Dec 2015 14:30:14 -0500
Message-ID: <CAPkFh0vY7sSFJxAnYSWgPszY6kAjcfDBR7cPn0ptL9yc-OtFdg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114a7c9cbedce70527fa5677
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
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: Mon, 28 Dec 2015 19:30:36 -0000
--001a114a7c9cbedce70527fa5677
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Do you specifically mean selfish mining as defined in Emin G=C3=BCn
> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
> issue in a scenario - one malicious miner with >30% hashing power -
> where you're already very close to the margins anyway; the difference
> between a 50% attack threshold and a 30% attack threshold isn't very
> significant.
>
This is not quite right: we know that selfish mining is a guaranteed win
at 34%. We do not know when exactly it begins to pay off. The more
consolidated and centralized the other mining pools, the less of a threat
it is below 34%; the more decentralized, the more likely it is to pay off
at lower thresholds.
Far more concerning is network propagation effects between large and
> small miners.
On a related note, the Bitcoin-NG paper took a big step towards moving
these kinds of concerns out of the realm of gut-feelings and wavy hands
into science. In particular, it introduced metrics for fairness (i.e.
differential
rate in orphans experienced by small and large miners), hash power
efficiency, as well as consensus delay.
> For that class of issues, if you are in an environemnt
> where selfish mining is possible - a fairly flat, easily DoS/sybil
> attacked network topology - the profitability difference between small
> and large miners even *without* attacks going on is a hugely worrying
> problem.
Indeed, there is a slight, quantifiable benefit to larger pools. Which is
why
we need to be diligent about not letting pools get too big.
> Note though that Eligius is *not* the only pool to have had problems
>
with block withholding, though AFAIK Eligius is the only one who has
> gone on record so far. (as I said in my original post, I'm relaying
> information given to me under condition of confidentiality)
>
I can see why they don't want to go public with this: it means that they
are less profitable than other pools.
It still looks to me like Ittay's discovery is doing exactly the right
thing:
this pool will need to be more careful when signing up new people,
curbing its otherwise steady march towards the 51% boundary.
- egs
- egs
--001a114a7c9cbedce70527fa5677
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">Do you specifically mean selfish mining as =
defined in Emin G=C3=BCn<br>
Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significan=
t<br>
issue in a scenario - one malicious miner with >30% hashing power -<br>
where you're already very close to the margins anyway; the difference<b=
r>
between a 50% attack threshold and a 30% attack threshold isn't very<br=
>
significant.<br></blockquote><div><br></div><div>This is not quite right: w=
e know that selfish mining is a guaranteed win</div><div>at 34%. We do not =
know when exactly it begins to pay off. The more=C2=A0</div><div>consolidat=
ed and centralized the other mining pools, the less of a threat</div><div>i=
t is below 34%; the more decentralized, the more likely it is to pay off=C2=
=A0</div><div>at lower thresholds.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
Far more concerning is network propagation effects between large and<br>
small miners. </blockquote><div><br></div><div>On a related note, the Bitco=
in-NG paper took a big step towards moving</div><div>these kinds of concern=
s out of the realm of gut-feelings and wavy hands=C2=A0</div><div>into scie=
nce. In particular, it introduced metrics for fairness (i.e. differential</=
div><div>rate in orphans experienced by small and large miners), hash power=
=C2=A0</div><div>efficiency, as well as consensus delay.=C2=A0</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">For that class of issues, if you=
are in an environemnt<br>
where selfish mining is possible - a fairly flat, easily DoS/sybil<br>
attacked network topology - the profitability difference between small<br>
and large miners even *without* attacks going on is a hugely worrying<br>
problem. </blockquote><div><br></div><div>Indeed, there is a slight, quanti=
fiable benefit to larger pools. Which is why</div><div>we need to be dilige=
nt about not letting pools get too big.</div><div>=C2=A0<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">Note though that Eligius is *not* the only pool to ha=
ve had problems<br></blockquote><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
with block withholding, though AFAIK Eligius is the only one who has<br>
gone on record so far. (as I said in my original post, I'm relaying<br>
information given to me under condition of confidentiality)<br></blockquote=
><div><br></div><div>I can see why they don't want to go public with th=
is: it means that they</div><div>are less profitable than other pools.=C2=
=A0</div><div><br></div><div>It still looks to me like Ittay's discover=
y is doing exactly the right thing:</div><div>this pool will need to be mor=
e careful when signing up new people,=C2=A0</div><div>curbing its otherwise=
steady march towards the 51% boundary.</div><div><br></div><div>- egs</div=
><div><br></div><div><br></div><div>- egs</div><div><br></div></div></div><=
/div>
--001a114a7c9cbedce70527fa5677--
|
