MIME-Version: 1.0
In-Reply-To: <CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
References: <CAPg+sBj-wA1DMrwkQRWnzQoB5NR-q=2-5=WDAAUYfSpXRZSTqw@mail.gmail.com>
	<CABsx9T1NqBX9Tr8vRCtCeri76e0wrtkvRhEPyG9Advv_3Uqxng@mail.gmail.com>
Date: Thu, 30 Jul 2015 19:46:30 +0200
Message-ID: <CABm2gDqC=-fvxSxCOd0s_3+iuatW54oWUPMHqW4EJ3fng-gOMw@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size following technological growth
Precedence: list

On Thu, Jul 30, 2015 at 6:20 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Jul 30, 2015 at 10:25 AM, Pieter Wuille via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> So we'd get to 2MB blocks in the year 2021. I think that is much too
> conservative

When considering "too conservative" options, let's not forget that,
say, scheduling 2MB for 2020 doesn't preclude us from deciding that
was too conservative and schedule, say 4MB for 2018 later. The first
hardfork would be "useless", but it would set a "minimum increase"
that would have been useful if the second one never happened.

> I'll comment on using median time generally in Jorge's thread, but why does
> monotonically increasing matter for max block size? I can't think of a
> reason why a max block size of X bytes in block N followed by a max size of
> X-something bytes in block N+1 would cause any problems.

To be clear, for this concrete case block.nTime would just work just
fine. I just want us to decide on one of the options and uniformly
recommend that options for all cases in BIP99 [just renamed the file,
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.org ].
But, yes, please, let's discuss this in the other thread.