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: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0C138BC3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 17:33:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com
[209.85.217.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD380110
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 17:33:33 +0000 (UTC)
Received: by lblf12 with SMTP id f12so59585143lbl.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 13 Jul 2015 10:33:31 -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=ZXq250qsIimZcVztK4yAHgQrcDqjAWoFArsl8Fkc6WU=;
b=PXqRiUKFD4ItcPWuNMBkE81PGKC5xkht+gPlFfM2laW5x8R2NClv6e8xxPWJ2+0/wP
wHoRzqCIRuHflS5t6tO72f4fcyDwhksact1ElWLZSJU1B6LZ5+jYmxO5Ls/N3lpS2Hc3
CZXx/Fl/d+qlAJz69s9uJN1biDoXkFG9e2Tg2ZF6RvsCa3neqvpe/taaxT1ag0VZbQwk
4YC8Bt4SpplJHPuYqw4XJW6dsRvQ6cEAvYHK7Q4ZwJioQ+uE+y7tczD9JTICjWG9tfp6
xJjvKtQ/9PDVhTmRBhNHvyxiU1u8ZySWvCZYPS86faZgp7oxs1mgXDOXBoo7rBdSZG/p
l9Sw==
MIME-Version: 1.0
X-Received: by 10.112.63.201 with SMTP id i9mr33263167lbs.93.1436808811705;
Mon, 13 Jul 2015 10:33:31 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 13 Jul 2015 10:33:31 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Mon, 13 Jul 2015 10:33:31 -0700 (PDT)
In-Reply-To: <20150713160453.GB19337@savin.petertodd.org>
References: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>
<CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
<20150713160453.GB19337@savin.petertodd.org>
Date: Mon, 13 Jul 2015 10:33:31 -0700
Message-ID: <CABr1YTedpe+nAJDh6WdwSjxk_0Y-=pAuRLZvvKKS_srtUsAdvg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a11c3f386d501a6051ac51e5f
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: Mon, 13 Jul 2015 17:33:36 -0000
--001a11c3f386d501a6051ac51e5f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> On Sat, Jul 11, 2015 at 11:24:48AM +0200, Jorge Tim=C3=B3n wrote:
> > 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 make=
s
> 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.
>
> You're missing something really critical about what F2Pool/AntPool were
> (are?) doing: They're finding out about new blocks not by getting block
> headers from just anywhere, but by connecting to other pools' via
> stratum anonymously and determining what block hash they're telling the
> hashers at the pool to work on. (e.g. what prevblockhash is in the block
> header of shares being generated)
>
> If other pools try to fake this information they're immediately and
> directly losing money, because they're telling their own hashers to make
> invalid blocks. This of course has a high chance of being detected, and
> can easily be FUDed into "STOP MINING AT FOO POOL!" reardless of what
> the ivory tower game theory might say. The only hope the pools have is
> to somehow identify which connections correspond to other pools with
> high reliability and target just those connections - good luck on that.
>
>
> Anyway, all this concern about SPV mining is misguided: relying purely
> on SPV w/ low #'s of confirmations just isn't very smart. What SPV can
> do - at least while the inflation subsidy is still high - is give
> reasonable protection against your third-party-run trusted full nodes
> from lying to you, simply because doing so has well-defined costs in
> terms of energy to create fake blocks. Targetting enough people at once
> to make a fake block a worthwhile investment is difficult, particularly
> when you take into account how timing works in the defenders favor - the
> attacker probably only has a small % of hashing power, so they're going
> to wait a long time to find their fake block. Between that and a trusted
> third party-run full node you're probably reasonably safe, for now.
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000086007e31decd6eb80e07f77271ef50c69e1e6342161f4e5
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a11c3f386d501a6051ac51e5f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On Sat, Jul 11, 2015 at 11:24:48AM +0200, Jo=
rge Tim=C3=B3n wrote:<br>
> All miners should validate transactions precisely because of the lates=
t<br>
> attack you've described. Full miners can gain a lot from this atta=
ck to<br>
> leverage their full validation against spv miners who blindly spend en=
ergy<br>
> hashing on top of something that may be worthless crap. SPV mining mak=
es no<br>
> sense, but some miners claim they're doind it for very short perio=
ds of<br>
> time, which shouldn't be as bad as doing it all the time.<br>
><br>
> I think it would be more rational for them to keep mining on top of th=
e old<br>
> block until they've fully validated the new block (which shouldn&#=
39;t take so<br>
> long anyway), even if this slightly increases the orphan rate.<br>
<br>
You're missing something really critical about what F2Pool/AntPool were=
<br>
(are?) doing: They're finding out about new blocks not by getting block=
<br>
headers from just anywhere, but by connecting to other pools' via<br>
stratum anonymously and determining what block hash they're telling the=
<br>
hashers at the pool to work on. (e.g. what prevblockhash is in the block<br=
>
header of shares being generated)<br>
<br>
If other pools try to fake this information they're immediately and<br>
directly losing money, because they're telling their own hashers to mak=
e<br>
invalid blocks. This of course has a high chance of being detected, and<br>
can easily be FUDed into "STOP MINING AT FOO POOL!" reardless of =
what<br>
the ivory tower game theory might say. The only hope the pools have is<br>
to somehow identify which connections correspond to other pools with<br>
high reliability and target just those connections - good luck on that.<br>
<br>
<br>
Anyway, all this concern about SPV mining is misguided: relying purely<br>
on SPV w/ low #'s of confirmations just isn't very smart. What SPV =
can<br>
do - at least while the inflation subsidy is still high - is give<br>
reasonable protection against your third-party-run trusted full nodes<br>
from lying to you, simply because doing so has well-defined costs in<br>
terms of energy to create fake blocks. Targetting enough people at once<br>
to make a fake block a worthwhile investment is difficult, particularly<br>
when you take into account how timing works in the defenders favor - the<br=
>
attacker probably only has a small % of hashing power, so they're going=
<br>
to wait a long time to find their fake block. Between that and a trusted<br=
>
third party-run full node you're probably reasonably safe, for now.<br>
<br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000086007e31decd6eb80e07f77271ef50c69e1e6342161f4e5<br>
<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>
--001a11c3f386d501a6051ac51e5f--
|
