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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F2241013
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 11:38:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
[209.85.213.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A475F106
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 11:38:34 +0000 (UTC)
Received: by mail-ig0-f171.google.com with SMTP id m11so17018746igk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 03:38: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:date:message-id:subject:from:cc
:content-type; bh=/d3SsB98LMNYCQ9BvE+L8R2KZGeF9VN61aone4GRyM8=;
b=TWLkNFNXuVA3qPZ+Z2Al0Je9QZzxiiKnBw8vDynojAsogDxIQoiS/ceGcILCT0MHjK
EEGzMIsywItAFTf8bD0tFe2FAOuYjeUPsqGoImPKtmyg/w/REBeuWJ94QjXVfT/t9ss+
SozKv9Jtw+R3Gvg/05H+GrKQ1C1YiE3Jsm2x0ueQ4yH43xSlMKU5vbubpNKie3zoMv70
QQnG15XtUwPAi4LuzNGhR/bkZehgmXv7Bn7FqoO80u0YiBjNUVokwsyVKdo3fTwdxPLr
mB2+702aBDXpzoRB4OYVoje8reWVUpnPMfSaVh1n64HgUq7haTtuFrPWkljmdQc51Cfz
WdMg==
MIME-Version: 1.0
X-Received: by 10.50.171.202 with SMTP id aw10mr12980466igc.26.1450611514156;
Sun, 20 Dec 2015 03:38:34 -0800 (PST)
Received: by 10.79.77.75 with HTTP; Sun, 20 Dec 2015 03:38:34 -0800 (PST)
In-Reply-To: <CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
References: <20151219184240.GB12893@muck>
<CAAcC9yvh2ma2dFhNDEKs7vfXyQF9L+T0YtRvOsJ15AbfVti=cw@mail.gmail.com>
<219f125cee6ca68fd27016642e38fdf1@xbt.hk>
<CAAcC9ys_t7X0WpQ8W3577M8GLiA5sPV2F1BJ9qZbnMkE-1j3+Q@mail.gmail.com>
<aff8da46a69bdd7ef92ca87725866a5c@xbt.hk>
<CAPkFh0vNECi1OmBwki+8NNAQbe6EG2FEE4RR5z=kYVLLDFHUXg@mail.gmail.com>
Date: Sun, 20 Dec 2015 11:38:34 +0000
Message-ID: <CAE-z3OU=18VuV+9U9meg5fRxQt3MZnAnQ2jPN5QBNk+ZtSoJXw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=089e010d931a022c8e052752d086
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no 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: Sun, 20 Dec 2015 11:38:35 -0000
--089e010d931a022c8e052752d086
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 20, 2015 at 5:12 AM, Emin G=C3=BCn Sirer <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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 wo=
rk
> to B, but discard any full blocks it discovers.
>
I wonder if part of the problem here is that there is no pool identity
linked to mining pools.
If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.
If the various mining protocols were updated, they could allow checking
that the work has the domain name of the pool included. Pools would have
to include their domain name in the block header.
A pool which provides this service is publicly saying that they will not
use the block withholding attack. Any two pools which are doing it cannot
attack each other (since they have different domain names). This creates
an incentive for pools to start supporting the feature.
Owners of hashing power also have an incentive to operate with pools which
offer this identity. It means that they can ensure that they get a payout
from any blocks found.
Hosted mining is weaker, but even then, it is possible for mining hosts to
provide proof that they performed mining. This proof would include the
identity of the mining pool. Even if the pool was run by the host, it
would still need to have the name embedded.
Mining hosts might be able to figure out which of their customers actually
check the identity info, and then they could redirect the mining power of
those who generally don't check. If customers randomly ask for all of the
hashing power, right back to when they joined, then this becomes expensive.
Mining power directly owned by the pool is also immune to this effect.
--089e010d931a022c8e052752d086
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Dec 20, 2015 at 5:12 AM, Emin G=C3=BCn Sirer <span dir=3D"ltr"><<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr">=C2=A0An attacker pool (A) can take a certa=
in portion of its hashpower,<div>use it to mine on behalf of victim pool (B=
), furnish partial proofs of work</div><div>to B, but discard any full bloc=
ks it discovers.</div></div></blockquote><div><br></div><div>I wonder if pa=
rt of the problem here is that there is no pool identity linked to mining p=
ools.<br><br></div><div>If the mining protocols were altered so that miners=
had to indicate their identity, then a pool couldn't forward hashing p=
ower to their victim.=C2=A0 <br><br></div><div>If the various mining protoc=
ols were updated, they could allow checking that the work has the domain na=
me of the pool included.=C2=A0 Pools would have to include their domain nam=
e in the block header.<br><br></div><div>A pool which provides this service=
is publicly saying that they will not use the block withholding attack.=C2=
=A0 Any two pools which are doing it cannot attack each other (since they h=
ave different domain names).=C2=A0 This creates an incentive for pools to s=
tart supporting the feature.<br><br></div><div>Owners of hashing power also=
have an incentive to operate with pools which offer this identity.=C2=A0 I=
t means that they can ensure that they get a payout from any blocks found.<=
br><br></div><div>Hosted mining is weaker, but even then, it is possible fo=
r mining hosts to provide proof that they performed mining.=C2=A0 This proo=
f would include the identity of the mining pool.=C2=A0 Even if the pool was=
run by the host, it would still need to have the name embedded.=C2=A0 <br>=
<br></div><div>Mining hosts might be able to figure out which of their cust=
omers actually check the identity info, and then they could redirect the mi=
ning power of those who generally don't check.=C2=A0 If customers rando=
mly ask for all of the hashing power, right back to when they joined, then =
this becomes expensive.<br><br></div><div>Mining power directly owned by th=
e pool is also immune to this effect.<br></div></div></div></div>
--089e010d931a022c8e052752d086--
|
