Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqQhA-0002m2-Bf for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 18:38:52 +0000 X-ACL-Warn: Received: from hapkido.dreamhost.com ([66.33.216.122]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YqQh8-0003C5-Ue for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 18:38:52 +0000 Received: from homiemail-a3.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by hapkido.dreamhost.com (Postfix) with ESMTP id 2787B9ED07 for ; Thu, 7 May 2015 11:21:56 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 5C38E284082; Thu, 7 May 2015 11:21:50 -0700 (PDT) Received: from [192.168.0.6] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net [86.30.131.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPSA id 9DBC8284090; Thu, 7 May 2015 11:21:49 -0700 (PDT) Message-ID: <554BAD3B.2050404@jrn.me.uk> Date: Thu, 07 May 2015 19:21:47 +0100 From: Ross Nicoll User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bitcoin Dev References: <554A91BE.6060105@bluematt.me> <554BA032.4040405@bluematt.me> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030508090401080706080902" X-Spam-Score: 0.9 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [66.33.216.122 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1YqQh8-0003C5-Ue Subject: Re: [Bitcoin-development] Block Size Increase 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: Thu, 07 May 2015 18:38:52 -0000 This is a multi-part message in MIME format. --------------030508090401080706080902 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Can I just add my own support for this - as has been stated elsewhere in this discussion, hard forks are difficult, and risky. The earlier we have a decision, and the earlier the change goes into the code, the easier that is. Even if the decision was the actual block size change is fine to leave until 2020, I'd like to see the code committed ASAP so that every new install, and every upgrade from there on gets the new version. My personal opinion only is that 7 transactions a second is insanely limited even if the main chain does nothing but act as a backbone between other chains and transaction networks. I don't think that's overly controversial. I think 2016 is too early for a 20mb block size, though. I'm inclined to suggest a schedule of expansion, say to 2mb in 2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The intent would be to provide enough size pressure to motivate scaling work, while not limiting Bitcoin overly. Further, I think this highlights that we need more work on fees. Right now fees and transactions included are fairly naive, but I'd like to see the absolute block size limit as a hard upper bound, with miners imposing soft limits based on a balance cost of storage, number of outputs vs inputs (and therefore impact on the UTXOs), and risk of orphan blocks to determine which transactions are actually worth including in each block. If anyone has numbers on block size vs orphan rate that would be really useful, BTW. Ross On 07/05/2015 19:06, Mike Hearn wrote: > > I think you are rubbing against your own presupposition that > people must find and alternative right now. Quite a lot here do > not believe there is any urgency, nor that there is an immanent > problem that has to be solved before the sky falls in. > > > I have explained why I believe there is some urgency, whereby "some > urgency" I mean, assuming it takes months to implement, merge, test, > release and for people to upgrade. > > But if it makes you happy, imagine that this discussion happens all > over again next year and I ask the same question. > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------030508090401080706080902 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit Can I just add my own support for this - as has been stated elsewhere in this discussion, hard forks are difficult, and risky. The earlier we have a decision, and the earlier the change goes into the code, the easier that is.

Even if the decision was the actual block size change is fine to leave until 2020, I'd like to see the code committed ASAP so that every new install, and every upgrade from there on gets the new version.

My personal opinion only is that 7 transactions a second is insanely limited even if the main chain does nothing but act as a backbone between other chains and transaction networks. I don't think that's overly controversial. I think 2016 is too early for a 20mb block size, though. I'm inclined to suggest a schedule of expansion, say to 2mb in 2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The intent would be to provide enough size pressure to motivate scaling work, while not limiting Bitcoin overly.

Further, I think this highlights that we need more work on fees. Right now fees and transactions included are fairly naive, but I'd like to see the absolute block size limit as a hard upper bound, with miners imposing soft limits based on a balance cost of storage, number of outputs vs inputs (and therefore impact on the UTXOs), and risk of orphan blocks to determine which transactions are actually worth including in each block. If anyone has numbers on block size vs orphan rate that would be really useful, BTW.

Ross

On 07/05/2015 19:06, Mike Hearn wrote:
I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in.

I have explained why I believe there is some urgency, whereby "some urgency" I mean, assuming it takes months to implement, merge, test, release and for people to upgrade.

But if it makes you happy, imagine that this discussion happens all over again next year and I ask the same question.



------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------030508090401080706080902--