From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D370683D for ; Fri, 26 Jun 2015 18:32:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 49BB27C for ; Fri, 26 Jun 2015 18:32:50 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Fri, 26 Jun 2015 14:32:45 -0400 References: <558D6E26.4000004@bitcoins.info> To: bitcoin-dev@lists.linuxfoundation.org From: Milly Bitcoin Message-ID: <558D9AC8.3020805@bitcoins.info> Date: Fri, 26 Jun 2015 14:32:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] The need for larger blocks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 18:32:50 -0000 > Proposing inaction is not the way you convince people that bitcoin can > scale. > > People and businesses cannot perform any capacity planning and future > projections under the proposal of "economic change through inaction." > > There will be no growth, by your argument, until there is fee > pressure. And what happens then? It is not clear he is proposing "inaction." I am not sure what he is proposing other than being against knee-jerk reactions. He has also said he doesn't want to take on the responsibility of deciding on whether to approve hard fork changes which is understandable considering all the other things he is doing. Such a responsibility is probably too much of a burden to put on any one individual no matter who it is. The next step is to come up with a process to handle proposed hard-fork changes other than just to ask the Core maintainer to do it. Russ