On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
<andr...@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.

November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
Bitcoin-development mailing list

Reply via email to