summaryrefslogtreecommitdiff
path: root/f4/4459624a69f859974fc366b4d284dc235e4f26
blob: d4b7fca3eb00f1cc09fd8ae904a1fd11d118711b (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
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
Return-Path: <nathan@leastauthority.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 84F34BC3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 12:09:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com
	[209.85.214.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0546163
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 12:09:17 +0000 (UTC)
Received: by obbop1 with SMTP id op1so205733780obb.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 11 Jul 2015 05:09:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=PmT9M3ixPtsgpb6MEwIzVOjiQ7Wil20nhLjM1RmReNo=;
	b=d9JKPQHdysqAA6+EPqS0Xw79nAq/FLqst7WAotJkANxY+rSj6I8US9TdmIWR26Rlt6
	luwI+sKDSKCU/iKAtk8JN6UXhs27+Z6Z2++ZskxrNXGWrnAHN3npByBMqt7XSMeVjK31
	oCOYKs+i2uDp3KTwSfZ4ybM9TFt6DMHTwL131Q7cd+UCdsItZ08ZX2OONPDOHXIB93G9
	syd2MHY/R+Vg6aL2xIVHRINai8QlHJa5J4Nb+Qqg1oNYeo/VNq955sA2gtiQ5gD7s/xd
	yHYnapgWkmnl4IFRJykEzLFutc27IF9NYDF29BAcOt8CqAGpmsW101892Y4wj8cnqyoe
	UcrA==
X-Gm-Message-State: ALoCoQnXN8hBk90eNONlxYKpr6N/kceQVr8DaZsIATpgp8p0wA6uWGMPqJ3stVhAP8n7OvAb/5ND
MIME-Version: 1.0
X-Received: by 10.60.83.241 with SMTP id t17mr23649974oey.21.1436616556907;
	Sat, 11 Jul 2015 05:09:16 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Sat, 11 Jul 2015 05:09:16 -0700 (PDT)
In-Reply-To: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
	<CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
	<CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
Date: Sat, 11 Jul 2015 05:09:16 -0700
Message-ID: <CAFdHNGj8BXAazAtHZsPe0qwxjRaxn6fQ4G-==bLCqwp+QH09Kg@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=089e0112cd4a8de258051a985b6f
X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW,URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue.
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: Sat, 11 Jul 2015 12:09:18 -0000

--089e0112cd4a8de258051a985b6f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 11, 2015 at 2:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
> All miners should validate transactions precisely because of the latest
attack you've described.

The problem is one of individual incentives leading to a systemic problem.
"All X should do..." solutions which are oblivious to individual incentives
don't scale, eg: "If all factories avoid emitting pollution they don't pay
for..." does not work if individual factories save their own costs by
dumping into the environment.  No one wants environmental catastrophe, and
no one wants a blockchain where miners don't validate transactions, but
there may be a systemic problem of incentives.

The bitcoin.org claim that "about half" of miner capacity does SPV Mining,
is consistent with the incentives problem as I described it.  However, I
don't claim the state of mining is certainly due to these incentives and
not other incentives we haven't discussed.  Also, there may be other
incentives that outweigh this issue.


On Sat, Jul 11, 2015 at 3:39 AM, Tier Nolan <tier.nolan@gmail.com> wrote:

>
>
> On Sat, Jul 11, 2015 at 10:24 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wro=
te:
>
>> I think it would be more rational for them to keep mining on top of the
>> old block until they've fully validated the new block (which shouldn't t=
ake
>> so long anyway), even if this slightly increases the orphan rate.
>
>
> Increased orphan rate means that the network is (slightly) less secure.
>
> If miners have a 5% orphan rate, then an attacker can launch a 51% attack
> with 49% of the network.
>
> It isn't a massive difference, but it is there.
>
> As long as miners switch back to non-SPV mining after a timeout,
> SPV-mining is safe for everyone.
>
>
If there's any cost to non-SPV mining, and the chance that an incoming
block contains only valid transactions is very high, isn't there still an
incentive to make this timeout longer and longer?


The average cost to the miner from building on an invalid block is small,
> as long as invalid blocks only happen rarely.
>
>
Yes. If it's rare enough, then skipping transaction validation saves more
cost than the expected cost of mining atop an invalid block.  ... but if
everyone follows that logic, the chance is no longer rare.



> Miners still have an incentive to do full validation, so that they can
> include transactions and get transaction fees.
>
>
This is a good point.  If the benefit to skipping verification outweighs
expected transaction costs, then a non-validating miner might also choose
to mine empty blocks with only their coinbase.  (I recall hearing this
occurred somewhat regularly around 2013, but I haven't paid attention since
then.  How common are empty blocks these days?)

This is a benefit of the world where transaction fees approach or surpass
block reward.


SPV-mining is to prevent hashing hardware from having to waste power when
> it isn't needed.
>
>
It may be less of a problem if (when?) electricity costs dominate hardware
> capital costs.
>

Oh.  This is a different explanation than Peter Todd's I linked to above,
which claimed it was network latency in receiving transactions.

Could you explain this a bit more?  What is not needed, the hashing
hardware or the power?  How does SPV Mining affect that?

I'll bet there are many individual rationales for SPV-Mining, but
ultimately they come down to dropping a cost based on a bet about other
miners' behavior.





>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


--=20
Nathan Wilcox
Least Authoritarian

email: nathan@leastauthority.com
twitter: @least_nathan

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

<div dir=3D"ltr"><br>On Sat, Jul 11, 2015 at 2:24 AM, Jorge Tim=C3=B3n <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:jtimon@jtimon.cc" target=3D"_blank">jti=
mon@jtimon.cc</a>&gt;</span> wrote:<br>&gt; All miners should validate tran=
sactions precisely because of the latest attack you&#39;ve described.<div c=
lass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem is on=
e of individual incentives leading to a systemic problem.=C2=A0 &quot;All X=
 should do...&quot; solutions which are oblivious to individual incentives =
don&#39;t scale, eg: &quot;If all factories avoid emitting pollution they d=
on&#39;t pay for...&quot; does not work if individual factories save their =
own costs by dumping into the environment.=C2=A0 No one wants environmental=
 catastrophe, and no one wants a blockchain where miners don&#39;t validate=
 transactions, but there may be a systemic problem of incentives.<br></div>=
<div class=3D"gmail_extra"><br>The <a href=3D"http://bitcoin.org">bitcoin.o=
rg</a> claim that &quot;about half&quot; of miner capacity does SPV Mining,=
 is consistent with the incentives problem as I described it.=C2=A0 However=
, I don&#39;t claim the state of mining is certainly due to these incentive=
s and not other incentives we haven&#39;t discussed.=C2=A0 Also, there may =
be other incentives that outweigh this issue.<br></div><br><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Sat, Jul 11, 2015 at 3:39 AM, =
Tier Nolan <span dir=3D"ltr">&lt;<a href=3D"mailto:tier.nolan@gmail.com" ta=
rget=3D"_blank">tier.nolan@gmail.com</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote"><span class=3D"">On Sat, Jul 11, 2=
015 at 10:24 AM, Jorge Tim=C3=B3n <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
timon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">I think it would be mor=
e rational for them to keep mining on top of the old block until they&#39;v=
e fully validated the new block (which shouldn&#39;t take so long anyway), =
even if this slightly increases the orphan rate.
</blockquote><div><br></div></span><div>Increased orphan rate means that th=
e network is (slightly) less secure.<br></div><div><br></div><div>If miners=
 have a 5% orphan rate, then an attacker can launch a 51% attack with 49% o=
f the network.<br><br></div><div>It isn&#39;t a massive difference, but it =
is there.<br><br></div><div>As long as miners switch back to non-SPV mining=
 after a timeout, SPV-mining is safe for everyone.<br><br></div></div></div=
></div></blockquote><div><br></div><div>If there&#39;s any cost to non-SPV =
mining, and the chance that an incoming block contains only valid transacti=
ons is very high, isn&#39;t there still an incentive to make this timeout l=
onger and longer?<br></div><div>=C2=A0<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div=
 class=3D"gmail_quote"><div></div><div>The average cost to the miner from b=
uilding on an invalid block is small, as long as invalid blocks only happen=
 rarely.<br></div><br></div></div></div></blockquote><div><br></div><div>Ye=
s. If it&#39;s rare enough, then skipping transaction validation saves more=
 cost than the expected cost of mining atop an invalid block.=C2=A0 ... but=
 if everyone follows that logic, the chance is no longer rare.<br></div><di=
v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
</div>Miners still have an incentive to do full validation, so that they ca=
n include transactions and get transaction fees.<br><br></div></div></block=
quote><div><br></div><div>This is a good point.=C2=A0 If the benefit to ski=
pping verification outweighs expected transaction costs, then a non-validat=
ing miner might also choose to mine empty blocks with only their coinbase.=
=C2=A0 (I recall hearing this occurred somewhat regularly around 2013, but =
I haven&#39;t paid attention since then.=C2=A0 How common are empty blocks =
these days?)<br><br></div><div>This is a benefit of the world where transac=
tion fees approach or surpass block reward.<br></div><div><br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"></div><div>SPV-mining is to prevent hashing hardware from =
having to waste power when it isn&#39;t needed.<br>=C2=A0</div></div></bloc=
kquote><div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra">It may be less of a problem if (when?) elect=
ricity costs dominate hardware capital costs.<br></div></div></blockquote><=
div>=C2=A0</div></div><div>Oh.=C2=A0 This is a different explanation than P=
eter Todd&#39;s I linked to above, which claimed it was network latency in =
receiving transactions.<br><br>Could you explain this a bit more?=C2=A0 Wha=
t is not needed, the hashing hardware or the power?=C2=A0 How does SPV Mini=
ng affect that?<br><br></div><div>I&#39;ll bet there are many individual ra=
tionales for SPV-Mining, but ultimately they come down to dropping a cost b=
ased on a bet about other miners&#39; behavior.<br></div><div class=3D"gmai=
l_quote"><br><br><br><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex">
<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></div><br><br clear=3D"all"><br>-- <br><div class=3D=
"gmail_signature"><div dir=3D"ltr"><div class=3D"gmail_signature">Nathan Wi=
lcox<br>Least Authoritarian<br><br>email: <a href=3D"mailto:nathan@leastaut=
hority.com" target=3D"_blank">nathan@leastauthority.com</a><br>twitter: @le=
ast_nathan<br></div></div></div>
</div></div>

--089e0112cd4a8de258051a985b6f--