Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VeskU-0004Pf-Mr for Bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 20:33:46 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.52 as permitted sender) client-ip=209.85.215.52; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f52.google.com; Received: from mail-la0-f52.google.com ([209.85.215.52]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VeskT-000513-JP for Bitcoin-development@lists.sourceforge.net; Fri, 08 Nov 2013 20:33:46 +0000 Received: by mail-la0-f52.google.com with SMTP id ev20so2231456lab.25 for ; Fri, 08 Nov 2013 12:33:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.134.3 with SMTP id pg3mr12046265lbb.11.1383942818780; Fri, 08 Nov 2013 12:33:38 -0800 (PST) Received: by 10.112.63.164 with HTTP; Fri, 8 Nov 2013 12:33:38 -0800 (PST) In-Reply-To: References: <5279D49D.5050807@jerviss.org> <20131107034404.GA5140@savin> <20131107132442.GB22476@savin> Date: Fri, 8 Nov 2013 12:33:38 -0800 Message-ID: From: Gregory Maxwell To: "Andreas M. Antonopoulos" Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gmaxwell[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: medium.com] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VeskT-000513-JP Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] we can all relax now X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:33:46 -0000 On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos 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.