From: Peter Todd <pete@petertodd•org>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue.
Date: Mon, 13 Jul 2015 12:04:53 -0400 [thread overview]
Message-ID: <20150713160453.GB19337@savin.petertodd.org> (raw)
In-Reply-To: <CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]
On Sat, Jul 11, 2015 at 11:24:48AM +0200, Jorge Timón 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 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.
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-07-13 16:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-11 8:05 Nathan Wilcox
2015-07-11 9:24 ` Jorge Timón
2015-07-11 10:39 ` Tier Nolan
2015-07-11 12:09 ` Nathan Wilcox
2015-07-11 13:17 ` Tier Nolan
2015-07-11 15:04 ` Dave Hudson
2015-07-11 16:26 ` Tier Nolan
2015-07-12 18:37 ` Jorge Timón
2015-07-12 18:54 ` Tier Nolan
2015-07-13 16:04 ` Peter Todd [this message]
2015-07-13 17:33 ` Eric Lombrozo
2015-07-13 17:49 ` Eric Lombrozo
2015-07-11 15:34 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150713160453.GB19337@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jtimon@jtimon$(echo .)cc \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox