public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
Date: Fri, 3 Jul 2015 23:30:16 -0400	[thread overview]
Message-ID: <20150704033016.GA14836@savin.petertodd.org> (raw)
In-Reply-To: <CAAS2fgQR15_1JVbtSD2yS9o5cpY-rNLsxpzuaeW2sexbQMuwQg@mail.gmail.com>

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

On Sat, Jul 04, 2015 at 03:17:17AM +0000, Gregory Maxwell wrote:
> On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn@hotmail•com> wrote:
> > We need some analysis on why this has happened.  It appears the larger hashrate is violating BIP66.  Thus it appears the network is rejecting this BIP, though potentially accidentally.  If this is an accident, how is such a large portion of hashrate forking, and what can we do to avoid this in the future?
> 
> A near majority of the hashrate on the network appears to be SPV mining.

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.

Unfortunately the Bitcoin protocol lets you do that, and the extra % of
revenue makes a big difference when you take into account the low profit
margins of mining these days. BIP66 happened to trigger this issue this
time, but actually *any* miner creating an invalid block for *any*
reason would have done so with the software miners are running right
now.

-- 
'peter'[:-1]@petertodd.org
00000000000000001242e0216eb113f1c50e4c18ecfbc8b9c0224ec82ec391d6

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

  reply	other threads:[~2015-07-04  3:30 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 [this message]
2015-07-04  3:32     ` odinn
2015-07-04 10:04     ` Tier Nolan
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=20150704033016.GA14836@savin.petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=gmaxwell@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