From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YyvSd-00073Y-HH for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 05:06:59 +0000 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; Received: from nm21.bullet.mail.bf1.yahoo.com ([98.139.212.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YyvSc-0003TH-EB for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 05:06:59 +0000 Received: from [98.139.170.179] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2015 05:06:53 -0000 Received: from [68.142.230.78] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2015 05:06:53 -0000 Received: from [127.0.0.1] by smtp235.mail.bf1.yahoo.com with NNFMP; 31 May 2015 05:06:52 -0000 X-Yahoo-Newman-Id: 994207.22193.bm@smtp235.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IlECFC0VM1kHW2sL.K73Rj93Xyd26_NREuXI60_VKaWF8rJ U9qaRO1M4bW.f_WrqM4EmgA1HW5c0b7b5ZqbQysXic665WB09BEcgVbh6btk L9OmYS4kmvo3FlB5YyopplPTPiU.GjQ9Oh_K46pDmv6lwCM71vsBEoJ4gO_H JW2JehUeB6BedWRTS1_kdvJgS9m4Y7NVB0cabZg3JJpkFPfrp2SbCoVLAYJV 8lcE7.22IgU0UsweATzSzv1qQQabduHTAixdKl0oG5F6iK8h9xoKBKeSnuVF 8xPnV9gTPI8QMitnAq9F1IUTWa4G_IOAk00MORGf1ZKdD9O7qcMV8BulPINR ir1.l2hDop0QiAfG3Nvc3P2OnrSWXUimsGvBXo4utSiPvyBbNu9tajK1bZrr naXJpCcBqgUoAh.M8t2JUfH8wbXTP9hZUlKwG1HPwOg48Y7EKOeCNLINBFmk hYX3WapMa6X0wIdrnhNwvSZSzVoHhHeNdoVuU2sJyTF74qBQDKWD_tVHpUFW ZSApgRFzKuh0ErJyDtWxB1rhOYzbRkmdEWEOg X-Yahoo-SMTP: kMAkG6uswBCBwEfDAoIbXivsMA-- Message-ID: <1433048756.2156.15.camel@yahoo.com> From: gb To: Alex Mizrahi Date: Sun, 31 May 2015 17:05:56 +1200 In-Reply-To: References: <554BE0E1.5030001@bluematt.me> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kiwigb[at]yahoo.com) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.139.212.180 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YyvSc-0003TH-EB Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase Requirements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 05:06:59 -0000 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