Message-ID: <556CFC01.9030309@thinlink.com>
Date: Mon, 01 Jun 2015 17:42:41 -0700
From: Tom Harding <tomh@thinlink.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Adam Back <adam@cypherspace.org>
References: <CALqxMTHfU5+1ezP-Jnn5obpd621EHwpstseFzTjAvOdhDkfj=g@mail.gmail.com>	<CANEZrP3SGdpSkpi-1eBiUMD74NPnAr7sW=eZ8WCz7PU6FVQaBA@mail.gmail.com>
	<CALqxMTE57mEiG7VuEDSfBDswCeYPWRoa1DEY9iL=P0xLFu8YCA@mail.gmail.com>
In-Reply-To: <CALqxMTE57mEiG7VuEDSfBDswCeYPWRoa1DEY9iL=P0xLFu8YCA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] soft-fork block size increase (extension
 blocks)
Precedence: list

On 6/1/2015 10:21 AM, Adam Back wrote:
> if it stays as is for a year, in a wait and see, reduce spam, see
> fee-pressure take effect as it has before, work on improving improve
> decentralisation metrics, relay latency, and do a blocksize increment
> to kick the can if-and-when it becomes necessary and in the mean-time
> try to do something more long-term ambitious about scale rather than
> volume.

What's your estimate of the lead time required to kick the can,
if-and-when it becomes necessary?

The other time-series I've seen all plot an average block size.  That's
misleading, because there's a distribution of block sizes.  If you bin
by retarget interval and plot every single block, you get this

http://i.imgur.com/5Gfh9CW.png

The max block size has clearly been in play for 8 months already.