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 435C940D for ; Thu, 30 Jul 2015 20:32:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E60E149 for ; Thu, 30 Jul 2015 20:32:14 +0000 (UTC) Received: from cotinga.riseup.net (unknown [10.0.1.161]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 0181242180; Thu, 30 Jul 2015 20:32:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1438288333; bh=85gbtEwr6zDfV4X3c2xu6N4Y7+jpjgAphgLrqc6Pu0I=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cXHLHpYg+H4mdRdMk2ARkbzN4rz3leGdpC1FClKx/uxWZ6QJwLbD0/qijSh3/qT52 /8W0Xanlf/VfYXC1pf+RK6vMVGBnKAFYvSxRqlKY3lMxul+65E5/95D718+Jz3WikD aeVWVdV4bV/1nka5liutaQojw9s944S3mD4jzRkI= Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 885331C03CE Message-ID: <55BA89CB.5080806@riseup.net> Date: Thu, 30 Jul 2015 13:32:11 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: jl2012@xbt.hk, "bitcoin-dev@lists.linuxfoundation.org" References: <20150730181450.Horde.mXJp1wMjXROJvXZ_Vhv2RQ2@server47.web-hosting.com> In-Reply-To: <20150730181450.Horde.mXJp1wMjXROJvXZ_Vhv2RQ2@server47.web-hosting.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD, UNPARSEABLE_RELAY 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] A summary of block size hardfork proposals (and a softforking one) 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: Thu, 30 Jul 2015 20:32:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Great summary, thanks. Helpful to get general grasp of the main things out there. On 07/30/2015 11:14 AM, jl2012 via bitcoin-dev wrote: > Currently, there are 4 block size BIP by Bitcoin developers: > > BIP100 by Jeff: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > BIP101 by Gavin: > https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki > BIP102 by Jeff: https://github.com/bitcoin/bips/pull/173/files > BIP??? by Pieter (called "BIP103" below): > https://gist.github.com/sipa/c65665fc360ca7a176a6 > > To facilitate further discussion, I'd like to summarize these > proposals by a series of questions. Please correct me if I'm wrong. > Something like sigop limit are less controversial and are not > shown. > > Should we use a BIP34-like voting mechanism to initiate the > hardfork? BIP100, 102, 103: No BIP101: Yes > > When should we initiate the hardfork? BIP100: 2016-01-11 BIP101: 2 > weeks after 75% miner support, but not before 2016-01-11 BIP102: > 2015-11-11 BIP103: 2017-01-01 > > What should be the block size at initiation? BIP100: 1MB BIP101: > 8MB BIP102: 2MB BIP103: 1MB > > Should we allow further increase / decrease? BIP100: By miner > voting, 0.5x - 2x every 12000 blocks (~3 months) BIP101: Double > every 2 years, with interpolations in between (41.4% p.a.) BIP102: > No BIP103: +4.4% every 97 days (double every 4.3 years, or 17.7% > p.a.) > > The earliest date for a >=2MB block? BIP100: 2016-04-03 (assuming > 10 minutes block) BIP101: 2016-01-11 BIP102: 2015-11-11 BIP103: > 2020-12-27 > > What should be the final block size? BIP100: 32MB is the max, but > it is possible to reduce by miner voting BIP101: 8192MB BIP102: > 2MB BIP103: 2048MB > > When should we have the final block size? BIP100: Decided by > miners BIP101: 30 years after initiation BIP102: 2015-11-11 BIP103: > 2063-07-09 > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > I'd like to add to this some remarks that are from an earlier discussion Cameron Garnham added into a thread, at http://bitcoin-development.narkive.com/iHmMh6bZ/bitcoin-development-prop osed-alternatives-to-the-20mb-step-function#post65 "First off, I am glad that the idea of dynamic block size adjustment is gaining some attention, in particular the model that I proposed. I wanted to take some time and explain some of the philosophy of how, and why, I proposed this this particular model. When Bitcoin was first made, there was a 32MB block size limit; this was quickly found to be open to spam (and potentially DOS, as the code was not-at-all optimized to support large blocks), and was reduced to 1MB, this was a quick fix that was never intended to last; at some point the network should come to an understanding, a consensus if you will, of what (and how much) belongs in a block. The core point of this is that miners have always, and will always; hold the power, to decide what goes into blocks; this implicitly, obviously, includes how large blocks are. Miners are able to come any sort of agreement they wish, providing the bitcoin clients accept their blocks as valid." (...) "the proposal introducing a consensus protocol for block sizes; instead of just having a hard limit (enforced by everyone), instead, we have a constant factor above the average block size over a fixed intervals that is soft-forked by only the miners. (The next simplest mathematical construct). This proposal is entirely a soft-fork and may be implemented without changing any client code what so ever. In-fact, it could be implemented by only a simple 51% majority of miners, with-or-without gaining the wider community consensus." - -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVuonLAAoJEGxwq/inSG8CensH/29IwToehXVgEA44RZmUsIdn 5d2OCGZHOsinJKS9Uqtd5SfIDycXVVTV832KrxIUH1oC685iwVzBuA4hJQc2Z49A hNKs97N97iS2s3W6X/llbYz/3i3H6TQaCJGfK+XurFi6pxdC+4LgoUovtGaIsc8x z7iTD5F7FEhPmKU6uxw9GRRvKHJwyy0xWWNgBAJjdS7F5y7DR1VC9RhPehpU75Wt MGHrrogM41r+cNVDpNpnT42q0rAKC0IXjvY43ZoA/EFUoWkpaXI6jwKXtjqDjCP7 P8StjQ7eoeIkZWu1PwbfKStbF4Ob3Q7Xi+hQxCwciKdtfsLRFkdamzvpl/qh9wg= =Itr1 -----END PGP SIGNATURE-----