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
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
|
Return-Path: <j@toom.im>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8192B105E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 19:07:26 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A09FE120
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 19:07:25 +0000 (UTC)
Received: from [192.168.1.190] (63.135.62.197.nwinternet.com [63.135.62.197]
(may be forged)) (authenticated bits=0)
by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tBTJ7Lu7019628
(version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);
Tue, 29 Dec 2015 11:07:22 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed;
boundary="Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5.2
From: Jonathan Toomim <j@toom.im>
In-Reply-To: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
Date: Tue, 29 Dec 2015 11:08:16 -0800
Message-Id: <386A5974-2368-4CA5-93BC-0DD7D5DA9D3D@toom.im>
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>
<CAAre=ySPjm+cyLdBY_CZkLdfXE3OFYgECEUq05AyWfY0q1KuTQ@mail.gmail.com>
<CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@mail.gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
X-Mailer: Apple Mail (2.1878.6)
X-Sonic-CAuth: UmFuZG9tSVbiJx99LPgGGboCJQtZXKyFjBsYSdZrfEcSDbNeKV8Ytt2/ZDmZmBOZfAa0qiuGSVG9jaUIAffuwpzoHkUuQF/M
X-Sonic-ID: C;VGRxY1+u5RGeV/8vZz0oYQ== M;lAr0Y1+u5RGeV/8vZz0oYQ==
X-Sonic-Spam-Details: 3.8/5.0 by cerberusd
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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
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: Tue, 29 Dec 2015 19:07:26 -0000
--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42
Content-Type: multipart/alternative;
boundary="Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098"
--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Ultimately, a self-interested miner will chose to build on the block =
that leaves the most transaction fees up for grabs. (This usually means =
the smallest block.) It's an interesting question whether the default =
behavior for Core should be the rational behavior (build on the =
"smallest" block in terms of fees) or some other supposedly altruistic =
behavior (most BTCDD). This also applies to the decision of the "same =
time" threshold -- a selfish miner will not care if the blocks arrived =
at about the same time or not.
I currently do not have a strong opinion on what that behavior should =
be, although if the blocksize limit were increased substantially, I may =
prefer the selfish behavior because it ends up also being fail-safe =
(punishes selfish mining using large blocks or fee-stealing attempts).
On Dec 29, 2015, at 10:59 AM, Dave Scotese via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> There have been no decent objections to altering the block-selection =
mechanism (when two block solutions appear at nearly the same time) as =
described at
>=20
> http://bitcoin.stackexchange.com/questions/39226
>=20
> Key components are:
> Compute BitcoinDaysDestroyed using only transactions that have been in =
your mempool for some time as oBTCDD ("old BTCDD").
> Use "nearly the same time" to mean separated in time by your guess of =
the average duration of block propagation times.
> When two block solutions come in at nearly the same time, build on the =
one that has the most oBTCDD, rather than the one that came in first.
> The goal of this change is to reduce the profitability of withholding =
block solutions by severely reducing the chances that a block solved a =
while ago can orphan one solved recently. "Came in first" seems more =
easily gamed than "most oBTCDD". As I wrote there, "old coins is always =
a dwindling resource and global nodes willing to help cheat is probably =
a growing one."
>=20
> I will write a BIP if anyone agrees it's a good idea.
>=20
>=20
> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Far more concerning is network propagation effects between large and
> small miners. 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. OTOH, if you're blocksize is small enough that propagation =
time
> is negligable to profitability, then selfish mining attacks with <30%
> hashing power aren't much of a concern - they'll be naturally defeated
> by anti-DoS/anti-sybil measures.
>=20
> Let's agree that one factor in mining profitability is =
bandwidth/network reliability/stability. Why focus on that vs =
electricity contracts or vertically integrated chip manufacturers? =
Surely, sufficient network bandwidth is a more broadly available =
commodity than <$0.02/kwh electricity, for example. I'm not sure that =
your stranded hydroelectric miner is any more desirable than thousands =
of dorm room miners with access to 10gbit university connections and =
free electricity.
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
>=20
>=20
> --
> I like to provide some work at no charge to prove my value. Do you =
need a techie?
> I own Litmocracy and Meme Racing (in alpha).
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "He ought to find it more profitable to play by the rules" - Satoshi =
Nakamoto
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><div>Ultimately, a self-interested miner will chose =
to build on the block that leaves the most transaction fees up for =
grabs. (This usually means the smallest block.) It's an interesting =
question whether the default behavior for Core should be the rational =
behavior (build on the "smallest" block in terms of fees) or some other =
supposedly altruistic behavior (most BTCDD). This also applies to the =
decision of the "same time" threshold -- a selfish miner will not care =
if the blocks arrived at about the same time or =
not.</div><div><br></div><div>I currently do not have a strong opinion =
on what that behavior should be, although if the blocksize limit were =
increased substantially, I may prefer the selfish behavior because it =
ends up also being fail-safe (punishes selfish mining using large blocks =
or fee-stealing attempts).</div><div><br></div><br><div><div>On Dec 29, =
2015, at 10:59 AM, Dave Scotese via bitcoin-dev <<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
dir=3D"ltr"><div>There have been no decent objections to altering the =
block-selection mechanism (when two block solutions appear at nearly the =
same time) as described at <br><br><a =
href=3D"http://bitcoin.stackexchange.com/questions/39226">http://bitcoin.s=
tackexchange.com/questions/39226</a><br><br></div>Key components =
are:<br><ul><li>Compute BitcoinDaysDestroyed using only transactions =
that have been in your mempool for some time as oBTCDD ("old =
BTCDD").</li><li>Use "nearly the same time" to mean separated in time by =
your guess of the average duration of block propagation =
times.<br></li><li>When two block solutions come in at nearly the same =
time, build on the one that has the most oBTCDD, rather than the one =
that came in first.</li></ul><p>The goal of this change is to reduce the =
profitability of withholding block solutions by severely reducing the =
chances that a block solved a while ago can orphan one solved =
recently. "Came in first" seems more easily gamed than "most =
oBTCDD". As I wrote there, "<em>old coins</em> is always a =
dwindling resource and <em>global nodes willing to help cheat</em> is =
probably a growing one."<br></p><p>I will write a BIP if anyone agrees =
it's a good idea.<br></p></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly =
via bitcoin-dev <span dir=3D"ltr"><<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=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:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">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" =
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>&nbs=
p;wrote:<br>
Far more concerning is network propagation effects between large and<br>
small miners. 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. OTOH, if you're blocksize is small enough that propagation =
time<br>
is negligable to profitability, then selfish mining attacks with =
<30%<br>
hashing power aren't much of a concern - they'll be naturally =
defeated<br>
by anti-DoS/anti-sybil =
measures.<br></blockquote><div><br></div></span><div>Let's agree that =
one factor in mining profitability is bandwidth/network =
reliability/stability. Why focus on that vs electricity contracts or =
vertically integrated chip manufacturers? Surely, sufficient network =
bandwidth is a more broadly available commodity than <$0.02/kwh =
electricity, for example. I'm not sure that your stranded hydroelectric =
miner is any more desirable than thousands of dorm room miners with =
access to 10gbit university connections and free =
electricity.</div></div></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
rel=3D"noreferrer" =
target=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitco=
in-dev</a><br>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div =
class=3D"gmail_signature"><div dir=3D"ltr">I like to provide some work =
at no charge to prove my value. Do you need a techie? <br>I own <a =
href=3D"http://www.litmocracy.com/" target=3D"_blank">Litmocracy</a> and =
<a href=3D"http://www.memeracing.net/" target=3D"_blank">Meme Racing</a> =
(in alpha). <br>I'm the webmaster for <a =
href=3D"http://www.voluntaryist.com/" target=3D"_blank">The =
Voluntaryist</a> which now accepts Bitcoin.<br>I also code for <a =
href=3D"http://dollarvigilante.com/" target=3D"_blank">The Dollar =
Vigilante</a>.<br>"He ought to find it more profitable to play by the =
rules" - Satoshi Nakamoto</div></div>
</div>
_______________________________________________<br>bitcoin-dev mailing =
list<br><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li=
nuxfoundation.org</a><br>https://lists.linuxfoundation.org/mailman/listinf=
o/bitcoin-dev<br></blockquote></div><br></body></html>=
--Apple-Mail=_BB3F9C90-F8EB-4D62-A68C-36A716C15098--
--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJWgtohAAoJEIEuMk4MG0P1as0H/jb70xk0KQ/49VGzxO9S0WB5
Jb6mXlIhaiB9/VJCrPiUoSoI6pNxPuXl5j5oTtO8r8JoqLfqLRUAs7E2YIyH54Xj
UMu/1EuTdWTo1rZFhGBCWl/hR56XiRwbyKIrPWVPw9ntoA6EJoCjpjXfDJye419B
2Uel0UtXDxRgHQKjcYXmbspEu8/9qjBMtab/3Ds2TcxF7Ot37JNoSbLECyEtgo2H
6TjSp9dLwCWT42+aTHNKiPGaPgIE4V5QrXwsaRyWYt6uX410YEo+LyCthRyC/Vxq
pquw3gxQ4z0S4BkAj7GUkNSbKyp0oNtuX/O2GtHP1WOL7cQTwgueEfKiMjQ7kqs=
=rjfG
-----END PGP SIGNATURE-----
--Apple-Mail=_70AA736C-19C0-44A9-8F01-566018B97C42--
|