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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 5B6FDAAC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 15:34:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 473CE195
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 15:34:56 +0000 (UTC)
Received: by wiga1 with SMTP id a1so36529299wig.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 08:34:55 -0700 (PDT)
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=D8+5A3FQUGQ8I9GG+h/7AhOpCpVMWdMfq6u7Mi+Q+S0=;
b=I46cDByWueviBOFubR8yNXYKcz29ktVdfvJRy+i87FNjnj4qo8vhx/uSCVD/od4HRS
EmYik61sif78wWYuaF6HLXV/zsMlzgfWVy+MgdkJfoIRwJTmCRvXRk4gpL2mh8duweRp
1M8nDflpj4iwEXZdzqoOBzxM2QF/YUpu6ek9VqOXAplJtgg9LAnBo7KBq3Fva2aN2T/O
yXjQw9U3iYoJ3yZIiKYNdUi8waet8zqmMNktKMwmmXKrNAD9CWN8cpEKIlpgFzQgkQ9a
Vb/+BF5DJXLG7BnhZAtF68UAs/CbmVSOmRLttZFW3KPQGOtWtOID1Y31pU7OPBh91ozy
lYTw==
MIME-Version: 1.0
X-Received: by 10.180.101.138 with SMTP id fg10mr7672259wib.46.1436628894901;
Sat, 11 Jul 2015 08:34:54 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Sat, 11 Jul 2015 08:34:54 -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:34:54 -0400
Message-ID: <CADm_WcbQcCtenoinvVCeeKz8Pdqju=tTNkm+NB91PLBTeA0nXQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Nathan Wilcox <nathan@leastauthority.com>
Content-Type: multipart/alternative; boundary=f46d0444e9a5f46d6f051a9b3a15
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
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 15:34:57 -0000
--f46d0444e9a5f46d6f051a9b3a15
Content-Type: text/plain; charset=UTF-8
The miners with invalid blocks were punished with a loss of bitcoin
income...
On Sat, Jul 11, 2015 at 4: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
>
>
--f46d0444e9a5f46d6f051a9b3a15
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The miners with invalid blocks were punished with a loss o=
f bitcoin income...<div><br></div></div><div class=3D"gmail_extra"><br><div=
class=3D"gmail_quote">On Sat, Jul 11, 2015 at 4:05 AM, Nathan Wilcox <span=
dir=3D"ltr"><<a href=3D"mailto:nathan@leastauthority.com" target=3D"_bl=
ank">nathan@leastauthority.com</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Thesis: The disincentive miners have for ver=
ifying transactions is<br>problematic and weakens the network's robustn=
ess against forks.<br><br>According to the 2015-07-04 <a href=3D"http://bit=
coin.org" target=3D"_blank">bitcoin.org</a> alert [1]_ so-called "SPV =
Mining"<br>has become popular across a large portion of miners, and th=
is 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-m=
ining#cause" target=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/bitc=
oin-dev@lists.linuxfoundation.org/msg00404.html" target=3D"_blank">https://=
www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00404.html</a=
><br><br>If there is a cost to verifying transactions in a received block, =
then<br>there is an incentive to *not verify transactions*.=C2=A0 However, =
this is<br>balanced by the a risk of mining atop an invalid block.<br><br>I=
f we imagine all miners verify all transactions, except Charlie the<br>Chea=
pskate, then it's in Charlie's interest to forego transaction<br>ve=
rification.=C2=A0 If all miners make a similar wager, then in the extreme,<=
br>no miners verify any transactions, and the expected cost of skipping<br>=
transaction verification becomes very high.<br><br>Unfortunately, it's =
difficult to measure how many miners are not<br>validating transactions, si=
nce there's no evidence of this until they<br>mine atop on invalid bloc=
k. Because of this, I worry that over time,<br>more and more miners cut thi=
s particular corner, to save on costs.<br><br>If true, then the network con=
tinues to grow more brittle towards the kind<br>of forking-persistence beha=
vior we saw from 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 mi=
ners are neglecting transaction verification may choose to<br>forego a bloc=
k reward by throwing 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 fraction 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>twi=
tter: @least_nathan<br><br>Standard Disclaimer: I'm behind on dev archi=
ves, irc logs, bitcointalk,<br>the wiki...=C2=A0 if this has been discussed=
before I appreciate 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><br></div>
--f46d0444e9a5f46d6f051a9b3a15--
|
