Re: [bitcoin-dev] The Excessive-Block Gate: How a Bitcoin Unlimited Node Deals With Large Blocks

[Peter R <peter_r@gmx.com>]

[-- 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 --]