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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AB16BABF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 09:24:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4BFC711A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 09:24:49 +0000 (UTC)
Received: by wgov12 with SMTP id v12so80656622wgo.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 02:24:48 -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=qJ3RFlMHQsmotnkukXpeRVNGbjK154NySR3kGic2KXM=;
b=dXcUgWa7d/juW6AJjmwYrMSgl+bSsurNOLR6SOHGbZKXGoS01rZ4KcoCGPGMFpRBjR
KsioTO59zyJTsiDecqmBrQLIiyCLLk9K3yU8hCJnrZA8wNHdQpinrIeta84aIkYBwk+a
QzmCuq5KM7A8Z946HyNqWOgEKR1l+HG3DrIH7fcSsRqbcYLw03fOtCwsMOTMDNC2Jz75
fdZSAbCTHTsPYuD4I/yKD/bl+2YuV0EbEU/mturI7XwoTIkB44tct2S2rNG3XWK6aaOe
uFaMJAlp4KT2Lkvred0LKiGevD9FYZ6R91HfI6DfLuoKhr7bqlTiAKlb4Gq1qdTChnuf
dGFw==
X-Gm-Message-State: ALoCoQlUcV+b4anStRPV9jPBjFvekyTDfM3g/0WPkGgF2lriyIclVoXUSb9L4hNRRBXCZeptGEk1
MIME-Version: 1.0
X-Received: by 10.180.80.229 with SMTP id u5mr5144829wix.92.1436606688449;
Sat, 11 Jul 2015 02:24:48 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Sat, 11 Jul 2015 02:24:48 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Sat, 11 Jul 2015 02:24:48 -0700 (PDT)
In-Reply-To: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
Date: Sat, 11 Jul 2015 11:24:48 +0200
Message-ID: <CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Nathan Wilcox <nathan@leastauthority.com>
Content-Type: multipart/alternative; boundary=f46d04428e4058eb9c051a960fe7
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@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 09:24:51 -0000
--f46d04428e4058eb9c051a960fe7
Content-Type: text/plain; charset=UTF-8
All miners should validate transactions precisely because of the latest
attack you've described. Full miners can gain a lot from this attack to
leverage their full validation against spv miners who blindly spend energy
hashing on top of something that may be worthless crap. SPV mining makes no
sense, but some miners claim they're doind it for very short periods of
time, which shouldn't be as bad as doing it all the time.
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 take so
long anyway), even if this slightly increases the orphan rate.
On Jul 11, 2015 10:05 AM, "Nathan Wilcox" <nathan@leastauthority.com> wrote:
> Thesis: The disincentive miners have for verifying transactions is
> problematic and weakens the network's robustness against forks.
>
> According to the 2015-07-04 bitcoin.org alert [1]_ so-called "SPV Mining"
> has become popular across a large portion of miners, and this enabled the
> consensus-violating forks to persist. Peter Todd provides an explanation
> of the incentive for SPV Mining over in another thread [2]_.
>
> .. [1] https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause
>
> .. [2]
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html
>
> If there is a cost to verifying transactions in a received block, then
> there is an incentive to *not verify transactions*. However, this is
> balanced by the a risk of mining atop an invalid block.
>
> If we imagine all miners verify all transactions, except Charlie the
> Cheapskate, then it's in Charlie's interest to forego transaction
> verification. If all miners make a similar wager, then in the extreme,
> no miners verify any transactions, and the expected cost of skipping
> transaction verification becomes very high.
>
> Unfortunately, it's difficult to measure how many miners are not
> validating transactions, since there's no evidence of this until they
> mine atop on invalid block. Because of this, I worry that over time,
> more and more miners cut this particular corner, to save on costs.
>
> If true, then the network continues to grow more brittle towards the kind
> of forking-persistence behavior we saw from the July 4th (and 5th) forks.
>
> This gets weird. For example, a malicious miner which suspects a large
> fraction of miners are neglecting transaction verification may choose to
> forego a block reward by throwing an erroneous transaction into their
> winning block, then, as all the "SPV Miners" run off along a worthless
> chain, they can reap a higher reward rate due to controlling a larger
> network capacity fraction on the valid chain.
>
> Can we fix this?
>
> --
> Nathan Wilcox
> Least Authoritarian
>
> email: nathan@leastauthority.com
> twitter: @least_nathan
>
> Standard Disclaimer: I'm behind on dev archives, irc logs, bitcointalk,
> the wiki... if this has been discussed before I appreciate mentions of
> that fact.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--f46d04428e4058eb9c051a960fe7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">All miners should validate transactions precisely because of=
the latest attack you've described. Full miners can gain a lot from th=
is attack to leverage their full validation against spv miners who blindly =
spend energy hashing on top of something that may be worthless crap. SPV mi=
ning makes no sense, but some miners claim they're doind it for very sh=
ort periods of time, which shouldn't be as bad as doing it all the time=
.<br></p>
<p dir=3D"ltr">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 (whic=
h shouldn't take so long anyway), even if this slightly increases the o=
rphan rate.</p>
<div class=3D"gmail_quote">On Jul 11, 2015 10:05 AM, "Nathan Wilcox&qu=
ot; <<a href=3D"mailto:nathan@leastauthority.com">nathan@leastauthority.=
com</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"ltr">Thesis: The disincentive miners have for verifying transact=
ions is<br>problematic and weakens the network's robustness against for=
ks.<br><br>According to the 2015-07-04 <a href=3D"http://bitcoin.org" targe=
t=3D"_blank">bitcoin.org</a> alert [1]_ so-called "SPV Mining"<br=
>has become popular across a large portion of miners, and this enabled the<=
br>consensus-violating forks to persist. Peter Todd provides an explanation=
<br>of the incentive for SPV Mining over in another thread [2]_.<br><br>.. =
[1] <a href=3D"https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause" ta=
rget=3D"_blank">https://bitcoin.org/en/alert/2015-07-04-spv-mining#cause</a=
><br><br>.. [2] <a href=3D"https://www.mail-archive.com/bitcoin-dev@lists.l=
inuxfoundation.org/msg00404.html" target=3D"_blank">https://www.mail-archiv=
e.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html</a><br><br>If the=
re is a cost to verifying transactions in a received block, then<br>there i=
s an incentive to *not verify transactions*.=C2=A0 However, this is<br>bala=
nced by the a risk of mining atop an invalid block.<br><br>If we imagine al=
l miners verify all transactions, except Charlie the<br>Cheapskate, then it=
's in Charlie's interest to forego transaction<br>verification.=C2=
=A0 If all miners make a similar wager, then in the extreme,<br>no miners v=
erify any transactions, and the expected cost of skipping<br>transaction ve=
rification becomes very high.<br><br>Unfortunately, it's difficult to m=
easure how many miners are not<br>validating transactions, since there'=
s no evidence of this until they<br>mine atop on invalid block. Because of =
this, I worry that over time,<br>more and more miners cut this particular c=
orner, to save on costs.<br><br>If true, then the network continues to grow=
more brittle towards the kind<br>of forking-persistence behavior we saw fr=
om the July 4th (and 5th) forks.<br><br>This gets weird.=C2=A0 For example,=
a malicious miner which suspects a large<br>fraction of miners are neglect=
ing transaction verification may choose to<br>forego a block reward by thro=
wing an erroneous transaction into their<br>winning block, then, as all the=
"SPV Miners" run off along a worthless<br>chain, they can reap a=
higher reward rate due to controlling a larger<br>network capacity fractio=
n on the valid chain.<br><br>Can we fix this?<br><br>--<br>Nathan Wilcox<br=
>Least Authoritarian<br><br>email: <a href=3D"mailto:nathan@leastauthority.=
com" target=3D"_blank">nathan@leastauthority.com</a><br>twitter: @least_nat=
han<br><br>Standard Disclaimer: I'm behind on dev archives, irc logs, b=
itcointalk,<br>the wiki...=C2=A0 if this has been discussed before I apprec=
iate mentions of<br>that fact.<br><br></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>
--f46d04428e4058eb9c051a960fe7--
|
