From: Gregory Maxwell <gmaxwell@gmail•com>
To: "Andreas M. Antonopoulos" <andreas@rooteleven•com>
Cc: Bitcoin Dev <Bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] we can all relax now
Date: Fri, 8 Nov 2013 12:33:38 -0800 [thread overview]
Message-ID: <CAAS2fgTKZGBmXxwTHyOimoZH_2ffsCd=yLMLPvMAL9H=MsM78g@mail.gmail.com> (raw)
In-Reply-To: <CAFmyj8y2H8hR=T4Ogui09MPOzz1nydNDvNZug2GZ8bWiu+52wA@mail.gmail.com>
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
<andreas@rooteleven•com> wrote:
> Nicholas Weaver is reporting that pools have already started delaying
> blocks, something that hints at Selfish Mining, since Nov. 3rd.
> https://medium.com/something-like-falling/d321a2ef9317
>
> He dismisses other reasons for delayed block propagation.
>
> Any ideas on whether pools are already mucking around with block delaying
> tactics?
>
> I have no idea if this report is accurate or explained by some other issue
> in the network, does anyone here have a comment on this?
The BC.i timestamps have historically been inaccurate relative to my
local GPS clock measurements on my own nodes... but not just that, it
sounds like he's comparing block timestamps and bc.i numbers.
Thats insane, because it tells you the delay between when the miner
_started_ a work unit and when BC.i claims to have found it. Even
assuming bc.i's times were accurate and assuming miner clocks are
accurate (they are often not) you expect there to be be a gap because
it takes time to compute work, send it to the miner, search for a
valid nonce (an average of 2^31 hash operations, often executed
sequentially on a single core taking ten seconds or so on a lot of
hardware) and then return a result.
Evidence of selfish miners wouldn't be block timestamps (which are
inaccurate and controlled by miners anyways), or data on
blockchain.info (which is inaccurate and controlled by bc.i) ... but
the existence of an unusual amount of orphan blocks. High levels of
blocks are _necessary_ evidence of this sort of things, there can be
other explanations of high orphaning levels, but they're required here
and couldn't be faked.
next prev parent reply other threads:[~2013-11-08 20:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 5:33 kjj
2013-11-06 9:26 ` Frank F
2013-11-06 11:35 ` Jeff Garzik
2013-11-06 18:06 ` Christophe Biocca
2013-11-07 3:44 ` Peter Todd
2013-11-07 4:15 ` Kyle Jerviss
2013-11-07 4:33 ` Peter Todd
2013-11-07 4:59 ` Kyle Jerviss
2013-11-07 13:09 ` Peter Todd
2013-11-07 4:56 ` Gavin Andresen
2013-11-07 13:24 ` Peter Todd
2013-11-07 16:14 ` Mike Hearn
2013-11-07 18:28 ` Daniel Lidstrom
2013-11-08 19:49 ` Andreas M. Antonopoulos
2013-11-08 20:33 ` Gregory Maxwell [this message]
2013-11-15 10:58 ` Peter Todd
2013-11-07 8:07 ` Jannes Faber
2013-11-07 5:24 ` Kyle Jerviss
2013-11-06 18:17 ` Melvin Carvalho
2013-11-06 22:19 ` Jouke Hofman
2014-05-10 11:05 ` E willbefull
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='CAAS2fgTKZGBmXxwTHyOimoZH_2ffsCd=yLMLPvMAL9H=MsM78g@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=Bitcoin-development@lists$(echo .)sourceforge.net \
--cc=andreas@rooteleven$(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