From: "Jorge Timón" <jtimon@jtimon•cc>
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: Sun, 12 Jul 2015 20:37:19 +0200 [thread overview]
Message-ID: <CABm2gDrPesyv95UHfDCRThaEkAQQ+rdQ1FN0ad0mFX9hTRj33A@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWOoHfMaEN04CQ-j8tzmAr1+Evjh+tfHRDbF6F1jxykHA@mail.gmail.com>
On Sat, Jul 11, 2015 at 12:39 PM, 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.
If miners aren't validating the blocks they mine on top of, an
attacker can do more nasty things I think.
> As long as miners switch back to non-SPV mining after a timeout, SPV-mining
> is safe for everyone.
>
> The average cost to the miner from building on an invalid block is small, as
> long as invalid blocks only happen rarely.
>
> Miners still have an incentive to do full validation, so that they can
> include transactions and get transaction fees.
>
> SPV-mining is to prevent hashing hardware from having to waste power when it
> isn't needed.
As long as miners switch back to the new longest chain after they
validate the block, mining on top of the
non-most-work-but-surely-valid may be less risky than mining on top of
a most-work-but-potentially-invalid block.
This has risks too. In both cases, if they don't mine a block during
the block validation, everything is fine.
If they successfully SPV mine, they risk having mined on top of an
invalid block, which not only means lost coins for them but high risk
for regular SPV users.
If they successfully mine on top of the previous block, they start a
mini-race that they can win or not, but the impact to regular SPV
users is much lower.
The later may be slightly less profitable, but I bet the difference is
negligible. It would be interesting to know if miners actually did
this numbers and how (in case their model is incomplete or flawed).
It is important to note that while SPV mining requires you to produce
empty blocks, mining on the previous on top of the previous block
allows you to include transactions and earn fees.
In a future where block rewards aren't so overwhelmingly dominated by
subsidies, the numbers will run against SPV mining.
In a future without (or with negligible) subsidy, SPV mining is always
inferior to just keep mining on top of the same block you were mining
until you fully validate the next one.
> It may be less of a problem if (when?) electricity costs dominate hardware
> capital costs.
This seems correct (for both cases).
It's also less worrying the shorter the full validation time of a block is.
next prev parent reply other threads:[~2015-07-12 18:37 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 [this message]
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=CABm2gDrPesyv95UHfDCRThaEkAQQ+rdQ1FN0ad0mFX9hTRj33A@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--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