public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nathan Wilcox <nathan@leastauthority•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] SPV Mining reveals a problematic incentive issue.
Date: Sat, 11 Jul 2015 05:09:16 -0700	[thread overview]
Message-ID: <CAFdHNGj8BXAazAtHZsPe0qwxjRaxn6fQ4G-==bLCqwp+QH09Kg@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>

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

On Sat, Jul 11, 2015 at 2:24 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
> All miners should validate transactions precisely because of the latest
attack you've described.

The problem is one of individual incentives leading to a systemic problem.
"All X should do..." solutions which are oblivious to individual incentives
don't scale, eg: "If all factories avoid emitting pollution they don't pay
for..." does not work if individual factories save their own costs by
dumping into the environment.  No one wants environmental catastrophe, and
no one wants a blockchain where miners don't validate transactions, but
there may be a systemic problem of incentives.

The bitcoin.org claim that "about half" of miner capacity does SPV Mining,
is consistent with the incentives problem as I described it.  However, I
don't claim the state of mining is certainly due to these incentives and
not other incentives we haven't discussed.  Also, there may be other
incentives that outweigh this issue.


On Sat, Jul 11, 2015 at 3:39 AM, Tier Nolan <tier.nolan@gmail•com> wrote:

>
>
> On Sat, Jul 11, 2015 at 10:24 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
>> 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.
>
>
> Increased orphan rate means that the network is (slightly) less secure.
>
> If miners have a 5% orphan rate, then an attacker can launch a 51% attack
> with 49% of the network.
>
> It isn't a massive difference, but it is there.
>
> As long as miners switch back to non-SPV mining after a timeout,
> SPV-mining is safe for everyone.
>
>
If there's any cost to non-SPV mining, and the chance that an incoming
block contains only valid transactions is very high, isn't there still an
incentive to make this timeout longer and longer?


The average cost to the miner from building on an invalid block is small,
> as long as invalid blocks only happen rarely.
>
>
Yes. If it's rare enough, then skipping transaction validation saves more
cost than the expected cost of mining atop an invalid block.  ... but if
everyone follows that logic, the chance is no longer rare.



> Miners still have an incentive to do full validation, so that they can
> include transactions and get transaction fees.
>
>
This is a good point.  If the benefit to skipping verification outweighs
expected transaction costs, then a non-validating miner might also choose
to mine empty blocks with only their coinbase.  (I recall hearing this
occurred somewhat regularly around 2013, but I haven't paid attention since
then.  How common are empty blocks these days?)

This is a benefit of the world where transaction fees approach or surpass
block reward.


SPV-mining is to prevent hashing hardware from having to waste power when
> it isn't needed.
>
>
It may be less of a problem if (when?) electricity costs dominate hardware
> capital costs.
>

Oh.  This is a different explanation than Peter Todd's I linked to above,
which claimed it was network latency in receiving transactions.

Could you explain this a bit more?  What is not needed, the hashing
hardware or the power?  How does SPV Mining affect that?

I'll bet there are many individual rationales for SPV-Mining, but
ultimately they come down to dropping a cost based on a bet about other
miners' behavior.





>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
Nathan Wilcox
Least Authoritarian

email: nathan@leastauthority•com
twitter: @least_nathan

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

  reply	other threads:[~2015-07-11 12:09 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 [this message]
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='CAFdHNGj8BXAazAtHZsPe0qwxjRaxn6fQ4G-==bLCqwp+QH09Kg@mail.gmail.com' \
    --to=nathan@leastauthority$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tier.nolan@gmail$(echo .)com \
    /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