public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luv Khemani <luvb@hotmail.com>
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining
Date: Mon, 17 Aug 2015 16:42:44 +0800	[thread overview]
Message-ID: <BLU172-W10F7A109C917CD56E7DF4DC2790@phx.gbl> (raw)

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

Hi all,
  I previously mentioned in a post that i believe that technically nodes are capable of handling blocks an order of magnitude larger than the current blocksize limit, the only missing thing was an incentive to run them. I have been monitoring the blockchain for the past couple of weeks and am seeing that even miners who have all the incentives are for whatever reason struggling to download and validate much smaller blocks.
The data actually paints a very grim picture of the current bandwidth/validating capacity of the global mining network.
See the following empty blocks mined despite a non-trivial elapsed time from the previous block just from the past couple of days alone (Data from insight.bitpay.com):

EmptyBlock /Time since previous block/ Size of previous block(bytes)/Mined by====================================================370165  29s  720784  Antpool370160  31s  50129    BTCChinaPool370076  49s  469988  F2Pool370059  34s  110994  Antpool370057  73s  131603  Antpool
We have preceding blocks as small as 50KB with 30s passing and the miner continues to mine empty blocks via SPV mining.
The most glaring case is Block 370057 where despite 73s elapsing and the preceding block being a mere 131KB, the miner is unable to download/validate fast enough to include transactions in his block. Unless ofcourse the miner is mining empty blocks on purpose, which does not make sense as all of these pools do mine blocks with transactions when the elapsed time is greater.

This is a cause for great concern, because if miners are SPV mining for a whole minute for <750KB blocks, at 8MB blocks, the network will just fall apart as a significant portion of the hashing power SPV mines throughout. All a single malicious miner has to do is mine an invalid block on purpose, let these pools SPV mine on top of them while it mines a valid block free of their competition. Yes, these pools deserve to lose money in that event, but the impact of reorgs and many block orphans for anyone not running a full node could be disastrous, especially more so in the XT world where Mike wants everyone to be running SPV nodes. I simply don't see the XT fork having any chance of surviving if SPV nodes are unreliable. 
And if these pools go out of business, it will lead to even more mining centralization which is already too centralized today.

Can anyone representing these pools comment on why this is happening? Are these pools on Matt's relay network?



 		 	   		  

[-- Attachment #2: Type: text/html, Size: 3080 bytes --]

             reply	other threads:[~2015-08-17  8:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-17  8:42 Luv Khemani [this message]
2015-08-17  9:15 ` [bitcoin-dev] Miners are struggling with blocks far smaller than 750KB blocks and resorting to SPV mining jl2012
2015-08-17 11:18   ` Luv Khemani
2015-08-19 14:35 ` Jeff Garzik
2015-08-20 14:27 ` Timo Hanke

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=BLU172-W10F7A109C917CD56E7DF4DC2790@phx.gbl \
    --to=luvb@hotmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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