From: 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 19:54:38 +0100 [thread overview]
Message-ID: <CAE-z3OVTgmo0H-Z-f6jhc_kv96rJ_rSYuQyBcjrSHD6T++UAZg@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDrPesyv95UHfDCRThaEkAQQ+rdQ1FN0ad0mFX9hTRj33A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]
On Sun, Jul 12, 2015 at 7:37 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> 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.
>
It depends on how long they are waiting. If they receive a header, it is
very likely to be part of a valid block.
The more time that passes, the more likely that the header's block was
invalid after all.
This tradeoff is what the timeout takes into account. For a short period
of time after the header is received, it is probably valid but eventually,
as time passes without it being fully validated, it is more likely to be
false after all.
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.
>
With a 1 minute timeout, there is only a 10% chance they will find another
block.
It is important that when a header is marked as "probably invalid" that all
the header's children are also updated too. The whole chain times out.
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.
>
Agreed. Transaction only fees changes the whole incentive structure.
A fee pool has been suggested to keep things as they are now. All fees
(mint & tx fees) are paid into a fee pool. 1% of the total pool fund is
paid to the coinbase.
This keeps the total payout per block reasonably stable. On the other
hand, it removes the incentive to actually include transactions at all.
[-- Attachment #2: Type: text/html, Size: 2644 bytes --]
next prev parent reply other threads:[~2015-07-12 18:54 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 [this message]
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=CAE-z3OVTgmo0H-Z-f6jhc_kv96rJ_rSYuQyBcjrSHD6T++UAZg@mail.gmail.com \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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