public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter R <peter_r@gmx.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks
Date: Sat, 26 Nov 2016 15:35:49 -0800	[thread overview]
Message-ID: <6AAD09CF-937E-4D35-B70A-CFDAB84A6B32@gmx.com> (raw)
In-Reply-To: <2318925.r6f9XVyAit@cherry>

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

Great discussion, Sergio and Tom!

> I now think my reasoning and conclusions are based on a false premise: that BU block size policies for miners can be heterogeneous.


Right, miners who set their block size limits (BSL) above OR below the "effective BSL" are disadvantaged.  Imagine that we plot the distribution (by hash power) for all miners' BSLs.  We might get a chart that looks like this:

http://imgur.com/a/tWNr6 <http://imgur.com/a/tWNr6>

In this chart, the "effective BSL" is defined as the largest block size that no less than half the hash power will accept.  

If a block is mined with a size Q that is less than the "effective BSL," then all the hash power with BSLs between BSL_min and Q will be forked from the longest chain (until they update their software if they're running Core or until their acceptance depth is hit if they're running BU).  This wastes these miners' hash power.  

However, if a block is mined with a size Q that is greater than the effective BSL, then all the hash power with BSLs between Q and BSL_max will temporarily be mining on a "destined to be orphaned" chain.  This also wastes these miners' hash power.  

Therefore, it is in the best interest of miners to all set the same block size limit (and reliably signal in their coinbase TX what that limit is, as done by Bitcoin Unlimited miners).  

We have empirical evidence the miners in fact behave this way: 

(1) No major miner has ever set his block size limit to less than 1 MB (not even those such as Luke-Jr who think 1 MB is too big) because doing so would just waste money.  

(2) After switching to Bitcoin Unlimited, both ViaBTC and the Bitcoin.com pool temporarily set their BSLs to 2 MB and 16 MB, respectively (of course keeping their _generation limit_ at 1MB).  However, both miners quickly reduced these limits back to 1 MB when they realized how it was possible to lose money in an attack scenario.  (This actually surprised me because the only way they could lose money is if some _other_ miner wasted even more money by purposely mining a destined-to-be-orphaned block.)   

The follow-up article I'm working on is about the topics we're discussing now, particularly about how Bitcoin Unlimited's “node-scale” behavior facilitates the emergence of a fluid and organic block size limit at the network scale.  Happy to keep continue with this current discussion, however.

Best regards
Peter


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

  reply	other threads:[~2016-11-26 23:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 16:31 [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks Peter R
2016-11-25  1:39 ` Sergio Demian Lerner
2016-11-25 15:25   ` Tom Zander
2016-11-25 22:31     ` Sergio Demian Lerner
2016-11-25 23:45       ` Sergio Demian Lerner
2016-11-26 15:01         ` Tom Zander
2016-11-26 23:35           ` Peter R [this message]
2016-11-27  7:47             ` Tom Zander

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=6AAD09CF-937E-4D35-B70A-CFDAB84A6B32@gmx.com \
    --to=peter_r@gmx.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