Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of yahoo.com
	designates 98.139.212.180 as permitted sender)
	client-ip=98.139.212.180; envelope-from=kiwigb@yahoo.com;
	helo=nm21.bullet.mail.bf1.yahoo.com; 
Message-ID: <1433048756.2156.15.camel@yahoo.com>
From: gb <kiwigb@yahoo.com>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Date: Sun, 31 May 2015 17:05:56 +1200
In-Reply-To: <CAE28kUTSgrU0kY6zLHrZXAAP+XD2H=NqT8rE3jt6Cp+1qGkHRg@mail.gmail.com>
References: <554BE0E1.5030001@bluematt.me>
	<CAFzgq-xByQ1E_33_m3UpXQFUkGc78HKnA=7XXMshANDuTkNsvA@mail.gmail.com>
	<CABsx9T0kbRe31LMwk499MQUw225f5GGd67GfhXBezHmDqxkioA@mail.gmail.com>
	<CAE28kUTSgrU0kY6zLHrZXAAP+XD2H=NqT8rE3jt6Cp+1qGkHRg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
Precedence: list

Linear growth is indeed the 'simplest' model for growth so removes
concerns of complexity using such a growth model. Seems like it might be
a safe compromise between exponential growth, zero growth and buys some
time to observe the longer term scale network behaviour. 

A simple linear growth 'hard' technical limit could also be used
conjunction with the simple periodic soft dynamic limit adjustment (e.g.
1.5x of moving average) as discussed recently. So that the combination
provides for growth, with fee pressure, up until if/when the technical
hard limit is hit. And if we keep hitting the hard limit that signals a
market demand for ancillary layers to be built out, that has been
missing until now.

On Sun, 2015-05-31 at 01:05 +0300, Alex Mizrahi wrote:
>  
>         
>         Why 2 MB ?
> 
> 
> Why 20 MB? Do you anticipate 20x transaction count growth in 2016?
> 
> 
> Why not grow it by 1 MB per year?
> This is a safer option, I don't think that anybody claims that 2 MB
> blocks will be a problem.
> And in 10 years when we get to 10 MB we'll get more evidence as to
> whether network can handle 10 MB blocks.
> 
> 
> So this might be a solution which would satisfy both sides:
>   *  people who are concerned about block size growth will have an
> opportunity to stop it before it grows too much (e.g. with a soft
> fork),
>   *  while people who want bigger blocks will get an equivalent of 25%
> per year growth within the first 10 years, which isn't bad, is it?
> 
> 
> So far I haven't heard any valid arguments against linear growth.
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development