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
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mike@coinlab.com>) id 1SbhCK-0002Bc-NC
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Jun 2012 00:00:32 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com
designates 209.85.216.52 as permitted sender)
client-ip=209.85.216.52; envelope-from=mike@coinlab.com;
helo=mail-qa0-f52.google.com;
Received: from mail-qa0-f52.google.com ([209.85.216.52])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SbhCJ-0003cj-RL
for bitcoin-development@lists.sourceforge.net;
Tue, 05 Jun 2012 00:00:32 +0000
Received: by qabj34 with SMTP id j34so2327074qab.11
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Jun 2012 17:00:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type:x-gm-message-state;
bh=jp/dGCD2w6Cyjhv9yO3r3rcbOXS5kSSmk4XkxDwMDxw=;
b=oaZfzGWkglDz3zNo93Jh1orskC9R3OdtzSSYGnRorv5OZbP3dJcLL7pTjBh3N+QgtJ
gTZzNWK1Zxg9vwAn0e+PwIi2owcaw14PPCOW5Wod0STi/Y/BP2i2ynU7do3x+pqoDZHC
x4npnvI4Fr7g75DTygK3V1rt96NREEo59BfVIsEH2ic4qlDjjI/Yg++ehzh2sVxd2Ds2
b/HW0Wxlx9gz+tADDTEMsrU8/OeQwTTf0v9F6K6+p9Rcju9pFc8vqBbSkJE5h7HAaTbQ
WIvVRZ6pLiUsMo/1es2kA2p7FTHJr2UXIvxjOD07USOCF2Ysz34njZRTSsTJ7MO3RUdD
T1UQ==
MIME-Version: 1.0
Received: by 10.224.96.82 with SMTP id g18mr15193624qan.0.1338854426099; Mon,
04 Jun 2012 17:00:26 -0700 (PDT)
Received: by 10.229.242.14 with HTTP; Mon, 4 Jun 2012 17:00:25 -0700 (PDT)
In-Reply-To: <201206042105.27064.luke@dashjr.org>
References: <201206030052.17128.luke@dashjr.org>
<201206040204.57503.luke@dashjr.org>
<CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com>
<201206042105.27064.luke@dashjr.org>
Date: Mon, 4 Jun 2012 17:00:25 -0700
Message-ID: <CAErK2Cj8hciP2FNtmvCf726gEWdFjO6=W5j4yTCrEYKFtXMKPA@mail.gmail.com>
From: Mike Koss <mike@coinlab.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=20cf3074b3ec793ff504c1ae560a
X-Gm-Message-State: ALoCoQmzoYMI3vEMdntTXoPniSlOaRdO238N3YcdCpVL6jauSSbrWN/FyZM+k0aIMg9FOAH8CoUy
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1SbhCJ-0003cj-RL
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Defeating the block withholding attack
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 05 Jun 2012 00:00:32 -0000
--20cf3074b3ec793ff504c1ae560a
Content-Type: text/plain; charset=ISO-8859-1
I don't understand how your proposal will work for decentralized pools -
can you explain it more concretely?
What would the new block header look like?
What is required for a share to to be earned?
What is required for a block to be valid (added to Block Chain)?
I don't think I understand what you mean by NextBlockCandidate. Perhaps a
concrete example using difficulty 1.7 million would be instructive.
On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> > As I understand the attack, the attacker gets compensated for the shares
> > they earn, but the pool will be denied any valid blocks found. The
> > attacker DOES NOT have access to the Bitcoins earned in the unreported
> > block (only the mining pool has access to the Coinbase address and
> > transactions in the block).
>
> With decentralized pools, the attacker does have access to the block, and
> can
> potentially submit it to the Bitcoin network directly bypassing the pool
> if it
> benefits them to do so.
>
> > So it's a zero-net-cost attack for the attacker (but no chance of making
> a
> > profit) to hurt the pool operator.
>
> Because of the above, there is a possibility an attacker can make a profit.
>
> > The only way to detect such an attack now is to look for "unlucky"
> miners;
> > at the current difficulty, you can't detect this cheat until many
> millions
> > of shares have been earned w/o a qualifying block. Since an attacker can
> > also create many fake identities, they can avoid detection indefinitely
> by
> > abandoning each account after a million earned shares.
>
> There are other modes of detection, but nobody has bothered to implement
> them
> since attackers can easily do a simple workaround in an arms race.
>
> > I don't understand your proposal for fixing this. You would have to come
> > up with a scheme where:
> >
> > - The miner can detect a qualifying hash to earn a share.
> > - Not be able to tell if the hash is for a valid block.
>
> With my proposal, miners can find shares, but won't know if it's a valid
> block
> until the subsequent block is also found (that subsequent block might not
> end
> up being a real block in the big picture).
>
> > The way I would do this is to have a secret part (not shared with the
> > miners) of a block that is part of the merkle hash, which is also used
> in a
> > secondary hash. Difficulty is then divide into two parts: the first,
> > solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes).
> And
> > a second, solved by the pool (1 in Difficulty shares). A valid block
> would
> > have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> > accepted.
>
> This only works for centralized pools, which are contrary to the health of
> the
> Bitcoin network. Decentralized pools cannot have a secret.
>
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)
A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need
to know about Bitcoins.
--20cf3074b3ec793ff504c1ae560a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I don't understand how your proposal will work for decentralized pools =
- can you explain it more concretely?<div><br></div><div>What would the new=
block header look like?</div><div><br></div><div>What is required for a sh=
are to to be earned?</div>
<div><br></div><div>What is required for a block to be valid (added to Bloc=
k Chain)?</div><div><br></div><div>I don't think I understand what you =
mean by NextBlockCandidate. =A0Perhaps a concrete example using difficulty =
1.7 million would be instructive.</div>
<div><br><div class=3D"gmail_quote">On Mon, Jun 4, 2012 at 2:05 PM, Luke-Jr=
<span dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank"=
>luke@dashjr.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:<br>
> As I understand the attack, the attacker gets compensated for the shar=
es<br>
> they earn, but the pool will be denied any valid blocks found. =A0The<=
br>
> attacker DOES NOT have access to the Bitcoins earned in the unreported=
<br>
> block (only the mining pool has access to the Coinbase address and<br>
> transactions in the block).<br>
<br>
</div>With decentralized pools, the attacker does have access to the block,=
and can<br>
potentially submit it to the Bitcoin network directly bypassing the pool if=
it<br>
benefits them to do so.<br>
<div class=3D"im"><br>
> So it's a zero-net-cost attack for the attacker (but no chance of =
making a<br>
> profit) to hurt the pool operator.<br>
<br>
</div>Because of the above, there is a possibility an attacker can make a p=
rofit.<br>
<div class=3D"im"><br>
> The only way to detect such an attack now is to look for "unlucky=
" miners;<br>
> at the current difficulty, you can't detect this cheat until many =
millions<br>
> of shares have been earned w/o a qualifying block. =A0Since an attacke=
r can<br>
> also create many fake identities, they can avoid detection indefinitel=
y by<br>
> abandoning each account after a million earned shares.<br>
<br>
</div>There are other modes of detection, but nobody has bothered to implem=
ent them<br>
since attackers can easily do a simple workaround in an arms race.<br>
<div class=3D"im"><br>
> I don't understand your proposal for fixing this. =A0You would hav=
e to come<br>
> up with a scheme where:<br>
><br>
> - The miner can detect a qualifying hash to earn a share.<br>
> - Not be able to tell if the hash is for a valid block.<br>
<br>
</div>With my proposal, miners can find shares, but won't know if it=
9;s a valid block<br>
until the subsequent block is also found (that subsequent block might not e=
nd<br>
up being a real block in the big picture).<br>
<div class=3D"im"><br>
> The way I would do this is to have a secret part (not shared with the<=
br>
> miners) of a block that is part of the merkle hash, which is also used=
in a<br>
> secondary hash. =A0Difficulty is then divide into two parts: the first=
,<br>
> solved by the miner (earning a "share" - e.g., 1 in 4 Billio=
n hashes). =A0And<br>
> a second, solved by the pool (1 in Difficulty shares). =A0A valid bloc=
k would<br>
> have to exhibit a valid Share Hash AND a valid Pool Hash in order to b=
e<br>
> accepted.<br>
<br>
</div>This only works for centralized pools, which are contrary to the heal=
th of the<br>
Bitcoin network. Decentralized pools cannot have a secret.<br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Mike Koss<di=
v>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div><div><a hre=
f=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank">A Bitcoin P=
rimer</a>=A0- What you need to know about Bitcoins.</div>
<br>
</div>
--20cf3074b3ec793ff504c1ae560a--
|
