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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id EB709F31
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 21:51:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com
[209.85.218.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EBACF162
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 21:51:29 +0000 (UTC)
Received: by mail-oi0-f47.google.com with SMTP id l9so165941879oia.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Dec 2015 13:51:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=gQL+2glXuKr+Hh26Wu9hstnGC3uIDuhdYWbE14+7EUg=;
b=AKazzpor0lSjImU24KXxUlpt+ZWyv2to7j22CmuFIrJDYqbM85I9PQUYBCE5WRU83F
ou+Zxgq8PPboQkvV9JtfjL+byJDBGTWYROCwOIgXK9IkcUDgTbLZFQp+ye61dPRTrJjf
aUstglOBBmvqLUD5c6sOUTvz7b8GJ6oO/Q276a4py28hTOKOaO4Ig6eSiyp4OqpsO198
lxS5WDjjIFtxMPYj+bD4w9U5SVKwPGo/JhnCyCfdFoBwWohA+JDE8W5aCoxC1X6odLWk
S+OMPHbO/F2qn1TdmYpjucjrRtrz9QzarwJ8xzmCogUmhTqoLrBDKmuUBIPfPsGa523L
ZLHg==
MIME-Version: 1.0
X-Received: by 10.202.222.193 with SMTP id v184mr37238761oig.15.1451425889336;
Tue, 29 Dec 2015 13:51:29 -0800 (PST)
Sender: dscotese@gmail.com
Received: by 10.60.125.35 with HTTP; Tue, 29 Dec 2015 13:51:29 -0800 (PST)
In-Reply-To: <CAJfRnm6akNXAQkXtPNu_bVFA7uuDUmeQ6L9oONq06Jo7r=wMmA@mail.gmail.com>
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>
<CAJfRnm6akNXAQkXtPNu_bVFA7uuDUmeQ6L9oONq06Jo7r=wMmA@mail.gmail.com>
Date: Tue, 29 Dec 2015 13:51:29 -0800
X-Google-Sender-Auth: J5tjd2MIQEyVPdZTPhH7wJlwABM
Message-ID: <CAGLBAhfaOLNKSjM+6878j_3kYfbg8ZP+MqiHxUTmVKi48YHg6Q@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Allen Piscitello <allen.piscitello@gmail.com>
Content-Type: multipart/alternative; boundary=001a113d54d48d42430528106c90
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
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 21:51:31 -0000
--001a113d54d48d42430528106c90
Content-Type: text/plain; charset=UTF-8
It cannot possibly be enforced. Enforcement is not important when you're
setting defaults. In fact, you don't want to enforce defaults, but rather
allow anyone who cares to deviate from them to do so.
The importance of default behavior is proportional to the number of folks
who mess with the defaults, and that, among miners, is pretty small as far
as I know, at least in the area of deciding how to decide which block to
build on when two show up at nearly the same time.
On Tue, Dec 29, 2015 at 11:25 AM, Allen Piscitello <
allen.piscitello@gmail.com> wrote:
> How could this possibly be enforced?
>
> On Tue, Dec 29, 2015 at 12:59 PM, 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
>>
>> http://bitcoin.stackexchange.com/questions/39226
>>
>> 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."
>>
>> I will write a BIP if anyone agrees it's a good idea.
>>
>> 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.
>>>>
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>
>>
>> --
>> I like to provide some work at no charge to prove my value. Do you need a
>> techie?
>> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
>> <http://www.memeracing.net> (in alpha).
>> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>> which now accepts Bitcoin.
>> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>> "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
>>
>>
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--001a113d54d48d42430528106c90
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>It cannot possibly be enforced.=C2=A0 Enforcement is =
not important when you're setting defaults.=C2=A0 In fact, you don'=
t want to enforce defaults, but rather allow anyone who cares to deviate fr=
om them to do so.<br><br></div>The importance of default behavior is propor=
tional to the number of folks who mess with the defaults, and that, among m=
iners, is pretty small as far as I know, at least in the area of deciding h=
ow to decide which block to build on when two show up at nearly the same ti=
me.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 11:25 AM, Allen Piscitello <span dir=3D"ltr"><<a hre=
f=3D"mailto:allen.piscitello@gmail.com" target=3D"_blank">allen.piscitello@=
gmail.com</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">How could this possibly be enforced?</div><div class=3D"HOEnZb"><d=
iv class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese 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><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There have been no decent=
objections to altering the block-selection mechanism (when two block solut=
ions appear at nearly the same time) as described at <br><br><a href=3D"htt=
p://bitcoin.stackexchange.com/questions/39226" target=3D"_blank">http://bit=
coin.stackexchange.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 g=
uess of the average duration of block propagation times.<br></li><li>When t=
wo block solutions come in at nearly the same time, build on the one that h=
as 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 so=
lutions by severely reducing the chances that a block solved a while ago ca=
n orphan one solved recently.=C2=A0 "Came in first" seems more ea=
sily gamed than "most oBTCDD".=C2=A0 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"gma=
il_extra"><br><div class=3D"gmail_quote"><div><div>On Mon, Dec 28, 2015 at =
12:26 PM, Ivan Brightly via bitcoin-dev <span dir=3D"ltr"><<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@l=
ists.linuxfoundation.org</a>></span> wrote:<br></div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div><div><div dir=3D"ltr"><div class=3D"gmail_extra"><di=
v class=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: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=C2=A0<span dir=3D"ltr"><<a href=3D"mailt=
o:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a>></span>=C2=A0wrote:<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 tim=
e<br>
is negligable to profitability, then selfish mining attacks with <30%<br=
>
hashing power aren't much of a concern - they'll be naturally defea=
ted<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/netwo=
rk reliability/stability. Why focus on that vs electricity contracts or ver=
tically 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 mor=
e desirable than thousands of dorm room miners with access to 10gbit univer=
sity connections and free electricity.</div></div></div></div>
<br></div></div><span>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></span></blockquote></div><span><font color=3D"#888888"><br><br clear=
=3D"all"><br>-- <br><div><div dir=3D"ltr">I like to provide some work at no=
charge to prove my value. Do you need a techie?=C2=A0 <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 Vi=
gilante</a>.<br>"He ought to find it more profitable to play by the ru=
les" - Satoshi Nakamoto</div></div>
</font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>
</div></div></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 cha=
rge to prove my value. Do you need a techie?=C2=A0 <br>I own <a href=3D"htt=
p://www.litmocracy.com" target=3D"_blank">Litmocracy</a> and <a href=3D"htt=
p://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 Vigila=
nte</a>.<br>"He ought to find it more profitable to play by the rules&=
quot; - Satoshi Nakamoto</div></div>
</div>
--001a113d54d48d42430528106c90--
|
