MIME-Version: 1.0
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue.
Precedence: list

--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>
&gt; All miners should validate transactions precisely because of the lates=
t<br>
&gt; attack you&#39;ve described. Full miners can gain a lot from this atta=
ck to<br>
&gt; leverage their full validation against spv miners who blindly spend en=
ergy<br>
&gt; hashing on top of something that may be worthless crap. SPV mining mak=
es no<br>
&gt; sense, but some miners claim they&#39;re doind it for very short perio=
ds of<br>
&gt; time, which shouldn&#39;t be as bad as doing it all the time.<br>
&gt;<br>
&gt; I think it would be more rational for them to keep mining on top of th=
e old<br>
&gt; block until they&#39;ve fully validated the new block (which shouldn&#=
39;t take so<br>
&gt; long anyway), even if this slightly increases the orphan rate.<br>
<br>
You&#39;re missing something really critical about what F2Pool/AntPool were=
<br>
(are?) doing: They&#39;re finding out about new blocks not by getting block=
<br>
headers from just anywhere, but by connecting to other pools&#39; via<br>
stratum anonymously and determining what block hash they&#39;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&#39;re immediately and<br>
directly losing money, because they&#39;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 &quot;STOP MINING AT FOO POOL!&quot; 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 #&#39;s of confirmations just isn&#39;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&#39;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&#39;re probably reasonably safe, for now.<br>
<br>
--<br>
&#39;peter&#39;[:-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--