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 54CBA93E for ; Tue, 23 Jun 2015 21:00:59 +0000 (UTC) X-Greylist: delayed 00:05:08 by SQLgrey-1.7.6 Received: from darla.gnomon.org.uk (darla.gnomon.org.uk [93.93.131.22]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 518C3121 for ; Tue, 23 Jun 2015 21:00:58 +0000 (UTC) Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1]) by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id t5NKtfwJ017149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jun 2015 21:55:46 +0100 (BST) (envelope-from roy@darla.gnomon.org.uk) Received: (from roy@localhost) by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id t5NKteA6017148; Tue, 23 Jun 2015 21:55:40 +0100 (BST) (envelope-from roy) Date: Tue, 23 Jun 2015 21:55:40 +0100 From: Roy Badami To: Gavin Andresen Message-ID: <20150623205539.GB3192@giles.gnomon.org.uk> References: <20150623192838.GG30235@muck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase 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: Tue, 23 Jun 2015 21:00:59 -0000 > Consensus is that this process is too painful to go through once a year. I > agree. > > If you disagree and would like to see a Blocksize Council meet once a year > to issue a decree on what the maximum block size shall be for the next > year, then propose a process for who gets to sit on the Council and how > their decrees are enforced..... We could just as well say that the increases continue for 20 years, or until there is concensus to schedule a soft-fork to prevent further increase - whichever comes first. That is the case already, of course, since there is no way to prevent a modest supermajority of miners from pushing through a soft-fork. But explicitly accepting the possibility that the community might choose to cut the process short might make the BIP more palatable to some. It is also the reality: halting the blocksize increase before it hits the final 8GB limit is relatively easy, compared to the task of setting it in motion, so it does no real harm to set the "20 years" figure at the upper range of what we think is reasonable - even though under other circumstances one would probably say that extrapolating exponentials that far out would be foolhardy... roy