public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Nathan Wilcox <nathan@leastauthority.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue.
Date: Sat, 11 Jul 2015 11:24:48 +0200	[thread overview]
Message-ID: <CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com> (raw)
In-Reply-To: <CAFdHNGg2dezj4V-i-E6dRLp99nZMQ_ErKdBo0OgQJ=9WPm90jQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3176 bytes --]

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.
On Jul 11, 2015 10: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
>
>

[-- Attachment #2: Type: text/html, Size: 4092 bytes --]

  reply	other threads:[~2015-07-11  9:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-11  8:05 [bitcoin-dev] SPV Mining reveals a problematic incentive issue Nathan Wilcox
2015-07-11  9:24 ` Jorge Timón [this message]
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
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='CABm2gDoAa5F5crO4enKO-Qqb+Zd3=9b8ohBDYmrygsPSWdevoQ@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=nathan@leastauthority.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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