summaryrefslogtreecommitdiff
path: root/84/b413102e70e64ce6d7050a9863c284c5a01550
blob: 53edd19e657a21eea2d3286be1781d1b701591d3 (plain)
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
Return-Path: <allen.piscitello@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A02151199
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Dec 2015 19:25:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com
	[209.85.218.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B1FF2175
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Dec 2015 19:25:18 +0000 (UTC)
Received: by mail-oi0-f54.google.com with SMTP id o62so187165833oif.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 29 Dec 2015 11:25:18 -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=sH3Q4LT97Z/uY4ayYEBJq6nqJuZSg3H9b6tsMlnMsz4=;
	b=Q11GBuu7en39iUAI2j0ZVMdKtL6fFDx3t5YXV0xphn4PnD5vDuFBzUKot0YO2lLZu5
	SEv2qquJBsmyHi6684kNg0K96MZH8rlXArRHMyuKxyy0I3LxyIweCArOZmhakGj8sIg5
	5VeuM/9O1I/bANN82wSWdc1QP6AQpGOZgG/ddUS/DOLcHk+rokJfOCV5tNOXKjuh1zq6
	xWPXpSOG3IajDbRT8joVzmr3ZH5Dm4GcTmnFKq4KFUUkcobVpwBKreRiNvuo2Yv5L62G
	6PjUrtkH9EPZi56seoGnqgr/c0LhRPvCm8yE9S7BPfGKsZYP/sDjFdqUXsL9sECJOmVW
	lYzQ==
MIME-Version: 1.0
X-Received: by 10.202.84.12 with SMTP id i12mr35886521oib.133.1451417118038;
	Tue, 29 Dec 2015 11:25:18 -0800 (PST)
Received: by 10.76.24.101 with HTTP; Tue, 29 Dec 2015 11:25:17 -0800 (PST)
In-Reply-To: <CAGLBAhdqKLgK09s5Mp6C4nv0k4hHBYM5c8NpgP5G7J110NseqQ@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>
Date: Tue, 29 Dec 2015 13:25:17 -0600
Message-ID: <CAJfRnm6akNXAQkXtPNu_bVFA7uuDUmeQ6L9oONq06Jo7r=wMmA@mail.gmail.com>
From: Allen Piscitello <allen.piscitello@gmail.com>
To: Dave Scotese <dscotese@litmocracy.com>
Content-Type: multipart/alternative; boundary=001a113ad09ebde2df05280e6194
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: Wed, 30 Dec 2015 03:51:47 +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: Tue, 29 Dec 2015 19:25:19 -0000

--001a113ad09ebde2df05280e6194
Content-Type: text/plain; charset=UTF-8

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
>
>

--001a113ad09ebde2df05280e6194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How could this possibly be enforced?</div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Tue, Dec 29, 2015 at 12:59 PM,=
 Dave Scotese via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=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 bloc=
k-selection mechanism (when two block solutions appear at nearly the same t=
ime) as described at <br><br><a href=3D"http://bitcoin.stackexchange.com/qu=
estions/39226" target=3D"_blank">http://bitcoin.stackexchange.com/questions=
/39226</a><br><br></div>Key components are:<br><ul><li>Compute BitcoinDaysD=
estroyed using only transactions that have been in your mempool for some ti=
me as oBTCDD (&quot;old BTCDD&quot;).</li><li>Use &quot;nearly the same tim=
e&quot; 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 ne=
arly 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 reduc=
e the profitability of withholding block solutions by severely reducing the=
 chances that a block solved a while ago can orphan one solved recently.=C2=
=A0 &quot;Came in first&quot; seems more easily gamed than &quot;most oBTCD=
D&quot;.=C2=A0 As I wrote there, &quot;<em>old coins</em> is always a dwind=
ling resource and <em>global nodes willing to help cheat</em> is probably a=
 growing one.&quot;<br></p><p>I will write a BIP if anyone agrees it&#39;s =
a good idea.<br></p></div><div class=3D"gmail_extra"><br><div class=3D"gmai=
l_quote"><div><div class=3D"h5">On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brig=
htly via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@li=
sts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundatio=
n.org</a>&gt;</span> wrote:<br></div></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div><div class=3D"h5"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">On Mon, Dec 28, 2015 at 2:12 PM, P=
eter Todd via bitcoin-dev=C2=A0<span dir=3D"ltr">&lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linu=
xfoundation.org</a>&gt;</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&#39;re blocksize is small enough that propagation tim=
e<br>
is negligable to profitability, then selfish mining attacks with &lt;30%<br=
>
hashing power aren&#39;t much of a concern - they&#39;ll be naturally defea=
ted<br>
by anti-DoS/anti-sybil measures.<br></blockquote><div><br></div></span><div=
>Let&#39;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 &lt;$0.02/kwh electricity, for =
example. I&#39;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 class=3D"">__________________________________________=
_____<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 class=3D"HOEnZb"><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&#39;m the webmaster for <a href=3D"http://www.voluntary=
ist.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>&quot;He ought to find it more profitable to=
 play by the rules&quot; - Satoshi Nakamoto</div></div>
</font></span></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>

--001a113ad09ebde2df05280e6194--