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 48957904 for ; Fri, 13 Nov 2015 06:40:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id EBC5F124 for ; Fri, 13 Nov 2015 06:40:55 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id AAB4938A67A9; Fri, 13 Nov 2015 06:39:54 +0000 (UTC) X-Hashcash: 1:25:151113:bitcoin-dev@lists.linuxfoundation.org::Ksi1cA154XhqoVFA:fD/BZ X-Hashcash: 1:25:151113:1240902@gmail.com::seR++n0cTRP7KT3Y:byYGq X-Hashcash: 1:25:151113:johnsock@gmail.com::6=mc07Ib=Wc+jf88:+zH/ From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Chun Wang <1240902@gmail.com> Date: Fri, 13 Nov 2015 06:39:51 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201511130639.53410.luke@dashjr.org> X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,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: John Sacco Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M 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, 13 Nov 2015 06:40:56 -0000 On Friday, November 13, 2015 2:56:55 AM Chun Wang via bitcoin-dev wrote: > * 2 MB, 210000 <= height < 420000; It's impossible to have the entire network upgraded in the past. Furthermore, 1 MB is already too large a block size today. While blocks don't need to be as big as the limit, it's better to have the limit approximate what is reasonably possible without straining the network. So while your proposed schedule change might be workable (if miners can be trusted to keep actual block size under 50% pending future improvements), I prefer the proposal beginning at the next subsidy halving (which we're well on the way to). Luke