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
|
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 C25FFAB2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 08:05:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com
[209.85.218.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05F22204
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 08:05:25 +0000 (UTC)
Received: by oiab3 with SMTP id b3so107212309oia.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 11 Jul 2015 01:05:25 -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:date:message-id:subject:from:to
:content-type;
bh=lSGVKWurPNoCnwA/oy9pzP2/44h9ksfTpZVUW2j1YTc=;
b=Y4eAeVfTWf7DBxqzEiUHsnXF0PyTJlZmJA6VOhIQiWo+XmhOSVVIsjiwBbJBkC5eEg
6XVvCdfg/lMhZWyvBbG0o3dsFtvUjkNkDQmL/xe6cqc2cM/VK3D2CjiefvAeobUusQy+
3aEW/HAdJ00KTf+LFYzuEKConhabYW9lXfqA7XXsVKJiqKaEvo/FNYYurX54P62CNswt
XDoIfZoHA7cIuVO50oOwUYG5fCgYmPHSly+sxte1taYwu32/V+AdRXejiHBbR8iA7dro
wBBq/+CKTyiORrobEHahH9HXFVjsueC+bFRBv2HAu/4p0mDRJxcMPTAuCA076Tg+4v59
B4bw==
X-Gm-Message-State: ALoCoQkuoKlDCnE8luHUbRMziwnfdrsNGuVBSKTENRuWKEjodXCFIkZJHL2Zn92eR9n6MKB9XGuT
MIME-Version: 1.0
X-Received: by 10.182.250.137 with SMTP id zc9mr3544056obc.79.1436601925215;
Sat, 11 Jul 2015 01:05:25 -0700 (PDT)
Received: by 10.182.47.229 with HTTP; Sat, 11 Jul 2015 01:05:25 -0700 (PDT)
Date: Sat, 11 Jul 2015 01:05:25 -0700
Message-ID: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
From: Nathan Wilcox <nathan@leastauthority.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e01537b226fc24f051a94f373
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
Subject: [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 08:05:26 -0000
--089e01537b226fc24f051a94f373
Content-Type: text/plain; charset=UTF-8
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.
--089e01537b226fc24f051a94f373
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thesis: The disincentive miners have for verifying transac=
tions is<br>problematic and weakens the network's robustness against fo=
rks.<br><br>According to the 2015-07-04 <a href=3D"http://bitcoin.org">bitc=
oin.org</a> alert [1]_ so-called "SPV Mining"<br>has become popul=
ar across a large portion of miners, and this enabled the<br>consensus-viol=
ating forks to persist. Peter Todd provides an explanation<br>of the incent=
ive for SPV Mining over in another thread [2]_.<br><br>.. [1] <a href=3D"ht=
tps://bitcoin.org/en/alert/2015-07-04-spv-mining#cause">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.linuxfoundation.org/msg00404.html">h=
ttps://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 Ho=
wever, this is<br>balanced by the a risk of mining atop an invalid block.<b=
r><br>If we imagine all miners verify all transactions, except Charlie the<=
br>Cheapskate, then it's in Charlie's interest to forego transactio=
n<br>verification.=C2=A0 If all miners make a similar wager, then in the ex=
treme,<br>no miners verify any transactions, and the expected cost of skipp=
ing<br>transaction verification becomes very high.<br><br>Unfortunately, it=
's difficult to measure how many miners are not<br>validating transacti=
ons, since there's no evidence of this until they<br>mine atop on inval=
id block. Because of this, I worry that over time,<br>more and more miners =
cut this particular corner, to save on costs.<br><br>If true, then the netw=
ork continues to grow more brittle towards the kind<br>of forking-persisten=
ce behavior we saw from the July 4th (and 5th) forks.<br><br>This gets weir=
d.=C2=A0 For example, a malicious miner which suspects a large<br>fraction =
of miners are neglecting transaction verification may choose to<br>forego a=
block reward by throwing an erroneous transaction into their<br>winning bl=
ock, then, as all the "SPV Miners" run off along a worthless<br>c=
hain, they can reap a higher reward rate due to controlling a larger<br>net=
work 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:n=
athan@leastauthority.com">nathan@leastauthority.com</a><br>twitter: @least_=
nathan<br><br>Standard Disclaimer: I'm behind on dev archives, irc logs=
, bitcointalk,<br>the wiki...=C2=A0 if this has been discussed before I app=
reciate mentions of<br>that fact.<br><br></div>
--089e01537b226fc24f051a94f373--
|
