Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gnomon.org.uk
	designates 93.93.131.22 as permitted sender)
	client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
	helo=darla.gnomon.org.uk; 
Date: Mon, 1 Jun 2015 21:15:03 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150601201503.GF13473@giles.gnomon.org.uk>
References: <CAE28kUT61qYxqV0mOqw5Dan=eMiCvnG2SnsAeWzOWTxwLydyeQ@mail.gmail.com>
	<CABsx9T2hfpts5y_M6PdDcxmq9Q2smesJ0Nmp9a9iyPD_MoPC9g@mail.gmail.com>
	<CAE28kUTZV3YsaSCX2d5YwLetnf=f+bOWGrwxLXdZFywTZ=+Pjg@mail.gmail.com>
	<CALC81CNq-GK5q6R4bmgHL5_Ej2+cZrtQMMLVmuhvMxkZokM3hQ@mail.gmail.com>
	<CAE28kUQr+kUPak67tcNQGGscUXtJiD1LiXfjdD8_LMUWyVdR5w@mail.gmail.com>
	<CANEZrP12WAcUOJp5UYg4pfWL7_4WiAHWWZAoaxAb5xB+qAP4Xg@mail.gmail.com>
	<CAFzgq-ykeMeWF-ndgSm9upHTe8j6ZFYhBQjFs_WSz1oVd29j7g@mail.gmail.com>
	<CAFzgq-x+-s_Nbt4z-C4SWQbHdPr159AmL2JvpP0zg1axM+Vwcw@mail.gmail.com>
	<CABsx9T2aEvPs68pQA-KrtaDQFcTTtiB36eqKAcJRkiOFQr6WsA@mail.gmail.com>
	<20150601200149.GE13473@giles.gnomon.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150601200149.GE13473@giles.gnomon.org.uk>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Precedence: list

On Mon, Jun 01, 2015 at 09:01:49PM +0100, Roy Badami wrote:
> > What do other people think?  Would starting at a max of 8 or 4 get
> > consensus?  Scaling up a little less than Nielsen's Law of Internet
> > Bandwidth predicts for the next 20 years?  (I think predictability is
> > REALLY important).
> 
> TL;DR: Personally I'm in favour of doing something relatively
> uncontroversial (say, a simple increase in the block size to something
> in the 4-8GB range) with no further increases without a further hard
> fork.

And the other bit I should have added to my TL;DR:

If we end up spending a significant proportion of the next 20 years
discussing the then _next_ hard fork, that's a *good* thing, not a
*bad* thing.  Hard forks need to become, if not entirely routine, then
certainly less scary.  A sequence of (relatively) uncontroversial hard
forks over time is way more likely to gain consensus than a single
hard fork that attempts to set a schedule for block size increases out
to 2035.  IMHO.

> 
> I'm not sure how relevent Nielsen's Law really is.  The only relevent
> data points Nielsen has really boil down to a law about how the speed
> of his cable modem connection has changed during the period 1998-2014.
> 
> Interesting though that is, it's not hugely relevent to
> bandwidth-intensive operations like running a full node.  The problem
> is he's only looking at the actual speed of his connection in Mbps,
> not the amount of data usage in GB/month that his provider permits -
> and there's no particular reason to expect that both of those two
> figures follow the same curve.  In particular, we're more interested
> in the cost of backhaul and IP transit (which is what drives the
> GB/month figure) than we are in improvements in DOCSIS technology,
> which have little relevence to node operators even on cable modem, and
> none to any other kind of full node operator, be it on DSL or in a
> datacentre.
> 
> More importantly, I also think a scheduled ramp up is an unnecessary
> complication.  Why do we need to commit now to future block size
> increases perhaps years into the future?  I'd rather schedule an
> uncontroversial hard fork now (if such thing is possible) even if
> there's a very real expectation - even an assumption - that by the
> time the fork has taken place, it's already time to start discussing
> the next one.  Any curve or schedule of increases that stretches years
> into the future is inevitably going to be controversial - and more so
> the further into the future it stretches - simply because the
> uncertainties around the Bitcoin landscape are going to be greater the
> further ahead we look.
> 
> If a simple increase from 1GB to 4GB or 8GB will solve the problem for
> now, why not do that?  Yes, it's quite likely we'll have to do it
> again, but we'll be able to make that decision in the light of the
> 2016 or 2017 landscape and can again make a simple, hopefully
> uncontroversial, increase in the limit at that time.
> 
> So, with the proviso that I think this is all bike shedding, if I had
> to pick my favourite colour for the bike shed, it would be to schedule
> a hard fork that increases the 1GB limit (to something in the 4-8GB
> range) but with no further increases without a further hard fork.
> 
> Personally I think trying to pick the best value of the 2035 block
> size now is about as foolish as trying to understand now the economics
> of Bitcoin mining many halvings hence.
> 
> NB: this is not saying that I think we shouldn't go above 8GB in the
> relatively foreseeable future; quite the contrary, I strongly expect
> that we will.  I just don't see the need to pick the 2020 block size
> now when we can easily make a far better informed decision as to the
> 2020 block size in 2018 or even 2019.
> 
> As to knowing what the block size is going to be for the next 20 years
> being "REALLY important"?  100% disagree.  I also think it's
> impossible, because even if you manage to get consensus on a block
> size increase schedule that stretches out to 2035 (and my prediction
> is you won't) the reality is that that block size schedule will have
> been modified by a future hard fork long before we get to 2035.
> 
> What I personally think is REALLY important is that the Bitcoin
> community demonstrates an ability to react appropriately to changing
> requirements and conditions - and we'll only be able to react to those
> conditions when we know what they are!  My expectation is that there
> will be several (hopefully _relatively_ uncontroversial) scheduled
> hard forks between now and 2035, and each of those will be discussed
> in suitable detail before being agreed.  And that's as it should be.
> 
> roy