From: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
Date: Sat, 4 Jul 2015 11:04:40 +0100 [thread overview]
Message-ID: <CAE-z3OVJE4Gtgu3jzqCOCWF04V7jKqXrhGbQ5z7dGM+oxo4MmA@mail.gmail.com> (raw)
In-Reply-To: <20150704033016.GA14836@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]
On Sat, Jul 4, 2015 at 4:30 AM, Peter Todd <pete@petertodd•org> wrote:
> As for what "SPV mining" is:
>
> While blocks are propagating throughout the network, frequently it's
> possible for miners to get the header of the block before they get and
> fully validate the block itself. This is just a few seconds to tens of
> seconds, but that's a big deal for profitability. So miners have been
> running custom patches that mine on top of the longest chain they know
> about, even if they haven't actually verified the blocks in it due to
> propagation delays.
>
Is the invalid fork pretty much all empty blocks then?
SPV mining isn't inherently dangerous, if it is only for a short period of
time. It can boost the total work for the block chain.
Inherently, invalid blocks are rare, so assuming a header is valid is the
correct assumption.
For safety (for the miner), SPV miners should switch back to full mining
after 20-30 seconds without fully validating the chain that they are on.
- header received
- header verified (they skipped this step)
- build on header with empty block
- receive full block
-- mark header as invalid if this step times out
- verify full block
-- mark header as invalid if verification fails
- build on full block with non-empty block
An easier rule is that you only build on a header if the header's parent
(or even grandparent) has been fully verified. That rule would prevent the
illegal fork from growing past 1-2 blocks. It would mean that SPV miners
would start wasting hashing power once the invalid fork hit 2 blocks. They
wouldn't even build on their own block.
I guess miners never added code of that kind? That is pretty shocking that
a majority would SPV mine without that safeguard against the main
vulnerability of SPV mining.
Even waiting a few minutes before switch back would protect against this.
Worse, in this case, is that it wasn't just an invalid block, it was an
invalid header chain. They could have done the check with headers only.
[-- Attachment #2: Type: text/html, Size: 2668 bytes --]
next prev parent reply other threads:[~2015-07-04 10:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-04 3:11 Raystonn
2015-07-04 3:17 ` Gregory Maxwell
2015-07-04 3:30 ` Peter Todd
2015-07-04 3:32 ` odinn
2015-07-04 10:04 ` Tier Nolan [this message]
2015-07-04 5:17 Raystonn
2015-07-04 5:22 ` Peter Todd
2015-07-04 5:40 ` odinn
2015-07-04 5:43 Raystonn
2015-07-04 5:44 ` Peter Todd
2015-07-04 15:18 ` Justus Ranvier
2015-07-04 15:35 ` Tier Nolan
2015-07-04 16:01 ` Justus Ranvier
2015-07-04 17:58 ` Tier Nolan
2015-07-04 23:33 ` Justus Ranvier
2015-07-05 1:32 ` Tier Nolan
2015-07-04 5:46 Raystonn
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-z3OVJE4Gtgu3jzqCOCWF04V7jKqXrhGbQ5z7dGM+oxo4MmA@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