[Bitcoin-dev-moderation] [bitcoin-dev] On Hardforks in the Context of SegWit

[Rusty Russell]

Aaron Voisine wrote:
> On Tue, Feb 9, 2016 at 1:54 PM, Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > The goal isnt really to get a "gain" here...its mostly to decrease the
> > worst-case (4MB is pretty crazy) and keep the total size in-line with
> > what the network could handle. Getting 1MB blocks through the network in
> > under a second is already incredibly difficult...2MB is pretty scary and
> > will take lots of work...3MB is over the bound of "yea, we can pretty
> > for sure get that to work pretty well".
> 
> Don't forget, this is the hard maximum block size limit we're talking
> about. Actual block sizes will obviously not reach the limit until they can
> be efficiently propagated with low orphan rates.
> 
> Aaron Voisine
> co-founder and CEO
> breadwallet <http://breadwallet.com/>

This is an FAQ; we've got a few of these recently, so I'll attempt to
respond to the rejection on bitcoin-dev-moderation at lists.ozlabs.org.

- Orphan rates are less for larger miners, so there's incentive for them
  to produce larger blocks at expense of smaller ones.
  - See also "selfish mining".

- Propogation is not all that efficient at the moment; some miners
  produce small (even empty) blocks deliberately to minimize orphaning,
  yet many others produce maximal blocks.  Reasons are complex, and not
  "obviously" at all.

- There seems a general consensus to design bitcoin for the worst-case.
  - See also two presentations from HK Scaling Bitcin:
        http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/security-assumptions/
        http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/in-adversarial-environments-blockchains-dont-scale/

Hope that helps shed some light on this fascinating area!

Cheers,
Rusty.