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: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E368FC88
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 12:42:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C2C0EC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 12:42:12 +0000 (UTC)
Received: by mail-wm0-f50.google.com with SMTP id l126so38158756wml.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Dec 2015 04:42:12 -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:to
:cc:content-type;
bh=cdprR2RAN0U0H8p0sqy42TpO1GrJwAAWY110Jdn/5jo=;
b=Q0M3T1AJZ90uaWqLLzsfpeF5znS8yZ7qpK5XBTKa/R5aUauM7sjP/ghIbTBxCY43EF
Wu7CjERXD4EYEv5J7yb7bHrtGzHp/PIk7UdXI4LapEw2134CKD84X3G4g4UqIOw3//pV
/euwNJylOL4ZaunS4KGyaavdssDH8rdJe04B/lqbFKmH/I8e2tZPkN5a2zdi6OJ1Z+Et
c+ZMNXawfKCbJLzgkftJHqPoXxEukfV+Un9PAJ++09CH1rRD4GBncwTWX+AE8xyrqzFK
EeEGJsLTGfrEk3Kxxu0RnJAY5Yvq8OlD4HCCx/mIH/wxNvyGeBHyAtHBW2ZtD2yhvHoE
+oTw==
MIME-Version: 1.0
X-Received: by 10.194.76.65 with SMTP id i1mr13945808wjw.99.1450615331443;
Sun, 20 Dec 2015 04:42:11 -0800 (PST)
Received: by 10.194.23.195 with HTTP; Sun, 20 Dec 2015 04:42:10 -0800 (PST)
Received: by 10.194.23.195 with HTTP; Sun, 20 Dec 2015 04:42:10 -0800 (PST)
In-Reply-To: <CAE-z3OU=18VuV+9U9meg5fRxQt3MZnAnQ2jPN5QBNk+ZtSoJXw@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>
<CAE-z3OU=18VuV+9U9meg5fRxQt3MZnAnQ2jPN5QBNk+ZtSoJXw@mail.gmail.com>
Date: Sun, 20 Dec 2015 13:42:10 +0100
Message-ID: <CAAt2M19QwL1AyH=pVARGa0zYKUtRM9hz8vXUzyZb05E5EhQMeA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=047d7bb03ece895e39052753b325
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 15:13:24 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 12:42:14 -0000
--047d7bb03ece895e39052753b325
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> 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
work
>> 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.
Our approaches can be combined.
Each pool (or solo miner) has a public key included in their blocks that
identifies them to their miners (solo miners can use their own unique
random keys every time). This public key may be registered with DNSSEC+DANE
and the pool could point to their domain in the block template as an
identifier.
For each block the pool generates a nonce, and for each of every miner's
workers it double-hashes that nonce with their own public key and that
miner's worker ID and the previous block hash (to ensure no accidental
overlapping work is done).
The double-hash is a commitment hash, the first hash is the committed value
to be used by the pool as described below. Publishing the nonce reveals how
the hashes were derived to their miners.
Each miner puts this commitment hash in their blocks, and also the public
key of the pool separately as mentioned above.
Here's where it differs from standard mining: both the candidate block PoW
hash and the pool's commitment value above determines block validity
together.
If total difficulty is X and the ratio for full blocks to candidate blocks
shared with the pool is Y, then the candidate block PoW now has to meet X/Y
while hashing the candidate block PoW + the pool's commitment hash must
meet Y, which together makes for X/Y*Y and thus the same total difficulty.
So now miners don't know if their blocks are valid before the pool does, so
withholding isn't effective, and the public key identifiers simultaneously
stops a pool from telling honest but naive miners to attack other pools
using whatever other schemes one might come up with.
The main differences are that there's a public key identifier the miners
are told about in advance and expect to see in block templates, and that
that now the pool has to publish this commitment value together with the
block that also contains the commitment hash, and that this is verified
together with the PoW.
--047d7bb03ece895e39052753b325
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linu=
xfoundation.org</a>>:<br>
><br>
> On Sun, Dec 20, 2015 at 5:12 AM, Emin G=C3=BCn Sirer <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundati=
on.org</a>> wrote:<br>
>><br>
>> =C2=A0An attacker pool (A) can take a certain portion of its hashp=
ower,<br>
>> use it to mine on behalf of victim pool (B), furnish partial proof=
s of work<br>
>> to B, but discard any full blocks it discovers.<br>
><br>
> I wonder if part of the problem here is that there is no pool identity=
linked to mining pools.<br>
><br>
> If the mining protocols were altered so that miners had to indicate th=
eir identity, then a pool couldn't forward hashing power to their victi=
m.=C2=A0 </p>
<p dir=3D"ltr">Our approaches can be combined. </p>
<p dir=3D"ltr">Each pool (or solo miner) has a public key included in their=
blocks that identifies them to their miners (solo miners can use their own=
unique random keys every time). This public key may be registered with DNS=
SEC+DANE and the pool could point to their domain in the block template as =
an identifier. </p>
<p dir=3D"ltr">For each block the pool generates a nonce, and for each of e=
very miner's workers it double-hashes that nonce with their own public =
key and that miner's worker ID and the previous block hash (to ensure n=
o accidental overlapping work is done).</p>
<p dir=3D"ltr">The double-hash is a commitment hash, the first hash is the =
committed value to be used by the pool as described below. Publishing the n=
once reveals how the hashes were derived to their miners. </p>
<p dir=3D"ltr">Each miner puts this commitment hash in their blocks, and al=
so the public key of the pool separately as mentioned above. </p>
<p dir=3D"ltr">Here's where it differs from standard mining: both the c=
andidate block PoW hash and the pool's commitment value above determine=
s block validity together. </p>
<p dir=3D"ltr">If total difficulty is X and the ratio for full blocks to ca=
ndidate blocks shared with the pool is Y, then the candidate block PoW now =
has to meet X/Y while hashing the candidate block PoW + the pool's comm=
itment hash must meet Y, which together makes for X/Y*Y and thus the same t=
otal difficulty.</p>
<p dir=3D"ltr">So now miners don't know if their blocks are valid befor=
e the pool does, so withholding isn't effective, and the public key ide=
ntifiers simultaneously stops a pool from telling honest but naive miners t=
o attack other pools using whatever other schemes one might come up with. <=
/p>
<p dir=3D"ltr">The main differences are that there's a public key ident=
ifier the miners are told about in advance and expect to see in block templ=
ates, and that that now the pool has to publish this commitment value toget=
her with the block that also contains the commitment hash, and that this is=
verified together with the PoW. </p>
--047d7bb03ece895e39052753b325--
|
