From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqR5U-0001OE-V4 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:04:00 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bluematt.me designates 192.241.179.72 as permitted sender) client-ip=192.241.179.72; envelope-from=bitcoin-list@bluematt.me; helo=mail.bluematt.me; Received: from mail.bluematt.me ([192.241.179.72]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1YqR5U-0008Bn-0t for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 19:04:00 +0000 Received: from [172.17.0.2] (gw.vpn.bluematt.me [162.243.132.6]) by mail.bluematt.me (Postfix) with ESMTPSA id F1A495437A; Thu, 7 May 2015 19:03:53 +0000 (UTC) Message-ID: <554BB718.6070104@bluematt.me> Date: Thu, 07 May 2015 19:03:52 +0000 From: Matt Corallo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Mike Hearn References: <554A91BE.6060105@bluematt.me> <554BA032.4040405@bluematt.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) 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 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YqR5U-0008Bn-0t Cc: Bitcoin Dev 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 19:04:01 -0000 Replies inline. On 05/07/15 17:43, Mike Hearn wrote: > The only answer to this that anyone with a clue should give is "it > will very, very likely be able to support at least 1MB blocks > roughly every 10 minutes on average for the next eleven years, and > it seems likely that a block size increase of some form will happen > at some point in the next eleven years", anything else is dishonest. > > > Matt, you know better than that. Gavin neither lacks clue nor is he > dishonest. No, I dont think Gavin is being deliberately dishonest, and I'm rather confident he phrased everything in a way that is technically true (ie the quote in his response). However, others have definitely not taken away the correct interpretation of what he said, and this is a serious problem. Setting expectations correctly as this is a very contentious issue and one that does not appear to be reaching consensus quickly in the technical community is important. More generally, consider the situation we're in now. Gavin is going off pitching this idea to the general public (which, I agree, is an important step in pulling off a hardfork) while people who actually study the issues are left wondering why they're being ignored (ie why is there no consensus-building happening on this list?). > He has been working on the assumption that other developers are > reasonable, and some kind of compromise solution can be found that > everyone can live with. Hence trying to find a middle ground, hence > considering and writing articles in response to every single objection > raised. Hence asking for suggestions on what to change about the plan, > to make it more acceptable. What more do you want, exactly? The appropriate method of doing any fork, that we seem to have been following for a long time, is to get consensus here and on IRC and on github and *then* go pitch to the general public (either directly or by releasing software) that they should upgrade. I admit that hardforks are a bit different in that the level of software upgrade required means additional lead time, but I'm not sure that means starting the public-pitching phase before there is any kind of consensus forming (actually, I'd point out that to me there seems to be rahter clear consensus outside of you and Gavin that we should delay increasing block size). As far as I can tell, there has been no discussion of block sizes on this list since 2013, and while I know Gavin has had many private conversations with people in this community about the block size, very little if any of it has happened in public. If, instead, there had been an intro on the list as "I think we should do the blocksize increase soon, what do people think?", the response could likely have focused much more around creating a specific list of things we should do before we (the technical community) think we are prepared for a blocksize increase. > And I'll ask again. Do you have a *specific, credible alternative*? > Because so far I'm not seeing one. A specific credible alternative to what? Committing to blocksize increases tomorrow? Yes, doing more research into this and developing software around supporting larger block sizes so people feel comfortable doing it in six months. I acknowledge that Gavin has been putting a lot of effort into this front, but, judging by this thread, I am far from the only one who thinks much more needs done.