Date: Tue, 23 Jun 2015 21:55:40 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Gavin Andresen <gavinandresen@gmail.com>
Message-ID: <20150623205539.GB3192@giles.gnomon.org.uk>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<20150623192838.GG30235@muck>
	<CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABsx9T2wsc=+seaWs=v5d_kPpC4u-xTnsjuPMO7PYhQN+0-KAQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

> Consensus is that this process is too painful to go through once a year.  I
> agree.
> 
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the Council and how
> their decrees are enforced.....

We could just as well say that the increases continue for 20 years, or
until there is concensus to schedule a soft-fork to prevent further
increase - whichever comes first.  That is the case already, of
course, since there is no way to prevent a modest supermajority of
miners from pushing through a soft-fork.  But explicitly accepting the
possibility that the community might choose to cut the process short
might make the BIP more palatable to some.

It is also the reality: halting the blocksize increase before it hits
the final 8GB limit is relatively easy, compared to the task of
setting it in motion, so it does no real harm to set the "20 years"
figure at the upper range of what we think is reasonable - even though
under other circumstances one would probably say that extrapolating
exponentials that far out would be foolhardy...

roy