diff options
| author | William Madden <will.madden@novauri.com> | 2015-06-23 23:05:50 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-24 03:05:56 +0000 |
| commit | 483f2c57d83cfeb198b276af0d7cd77c31ac0dd9 (patch) | |
| tree | e7569bcde08ad327a5ca00651f2ac82b4e4a58db | |
| parent | 14f344abc3d38aac60bcc205a44cc525d6b74b4d (diff) | |
| download | pi-bitcoindev-483f2c57d83cfeb198b276af0d7cd77c31ac0dd9.tar.gz pi-bitcoindev-483f2c57d83cfeb198b276af0d7cd77c31ac0dd9.zip | |
Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
| -rw-r--r-- | e9/4c04ef850c85d4ec940cfc35d447c1972c8f5d | 312 |
1 files changed, 312 insertions, 0 deletions
diff --git a/e9/4c04ef850c85d4ec940cfc35d447c1972c8f5d b/e9/4c04ef850c85d4ec940cfc35d447c1972c8f5d new file mode 100644 index 000000000..37bc1a524 --- /dev/null +++ b/e9/4c04ef850c85d4ec940cfc35d447c1972c8f5d @@ -0,0 +1,312 @@ +Return-Path: <will.madden@novauri.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D4A75AAE + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Jun 2015 03:05:56 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com + [209.85.220.175]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7B599E7 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 24 Jun 2015 03:05:55 +0000 (UTC) +Received: by qkbp125 with SMTP id p125so15364133qkb.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 23 Jun 2015 20:05:54 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:subject:to:references:from:message-id:date + :user-agent:mime-version:in-reply-to:content-type + :content-transfer-encoding; + bh=+CcCDo+MfFb2oBwVYOIovQ6hlzhMTN5YVSyFFk9VnRI=; + b=UQKAsNK9GPSaBA9L7ik1EkjMb4NinSznpFLmh5NgdLvkz/3KVzq3O6/9+sYE8cLFAM + g9cig3+jhZ5mn/nP2LkBU2F0g11Bd/c2hRh/Q4mUPtb01qZeo00PjlsoJocnqOOImWFM + awD0RizLUAcsg/AOVQJRI1YqjlUZXuv6PsJGSLgc87D6rwiCHGM7BKkXIhAaurOtlizS + 2KhN/ZK6In6IUmZaD2lcSUE67tBAa2v+BlW3cGPbv8BwbEkGOWEk1t7VDpRQQaIjVXdl + 5vRsSdGkleU4fmFYxs3TkJAbC9vSeU7J//F4VAvybRl0e3ybws01qt4GxegKBm29vtVt + gVoQ== +X-Gm-Message-State: ALoCoQnuG4NTkrcYoiLhUZsEt8Z7EVAEF7EMWTnNi7+0s4wJbxClsLWOszL0nJU8ccMS6U3InpV4 +X-Received: by 10.55.31.22 with SMTP id f22mr78688693qkf.33.1435115154757; + Tue, 23 Jun 2015 20:05:54 -0700 (PDT) +Received: from Williams-MacBook-Pro.local + (cpe-142-105-234-20.twcny.res.rr.com. [142.105.234.20]) + by mx.google.com with ESMTPSA id b77sm1306096qkb.8.2015.06.23.20.05.53 + for <bitcoin-dev@lists.linuxfoundation.org> + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Tue, 23 Jun 2015 20:05:53 -0700 (PDT) +To: bitcoin-dev@lists.linuxfoundation.org +References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com> + <558A0B4A.7090205@riseup.net> +From: William Madden <will.madden@novauri.com> +X-Enigmail-Draft-Status: N0210 +Message-ID: <558A1E8E.30306@novauri.com> +Date: Tue, 23 Jun 2015 23:05:50 -0400 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) + Gecko/20100101 Thunderbird/38.0.1 +MIME-Version: 1.0 +In-Reply-To: <558A0B4A.7090205@riseup.net> +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: 7bit +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW + 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] 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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 24 Jun 2015 03:05:56 -0000 + +Here are refutations of the approach in BIP-100 here: +http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf + +To recap BIP-100: + +1) Hard form to remove static 1MB block size limit +2) Add new floating block size limit set to 1MB +3) Historical 32MB message limit remains +4) Hard form on testnet 9/1/2015 +5) Hard form on main 1/11/2016 +6) 1MB limit changed via one-way lock in upgrade with a 12,000 block +threshold by 90% of blocks +7) Limit increase or decrease may not exceed 2x in any one step +8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase +scriptSig, e.g. "/BV8000000/" to vote for 8M. +9) Votes are evaluated by dropping bottom 20% and top 20%, and then the +most common floor (minimum) is chosen. + +8MB limits doubling just under every 2 years makes a static value grow +in a predictable manner. + +BIP-100 makes a static value grow (or more importantly potentially +shrink) in an unpredictable manner based on voting mechanics that are +untested in this capacity in the bitcoin network. Introducing a highly +variable and untested dynamic into an already complex system is +unnecessarily risky. + +For example, the largely arbitrary voting rules listed in 9 above can be +gamed. If I control pools or have affiliates involved in pools that +mine slightly more than 20% of blocks, I could wait until block sizes +are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and +"/BV5000001/" for the remaining 10%. If others don't consistently vote +for the same "/BV#/" value, vote too consistently and have their value +thrown out as the top 20%, I could win the resize to half capacity +"/BV5000001/" because it was the lowest repeated value not in the bottom +20%. + +I could use this to force an exodus to my sidechain/alt coin, or to +choke out the bitcoin network. A first improvement would be to only let +BIP-100 raise the cap and not lower it, but if I can think of a +vulnerability off the top of my head, there will be others on the other +side of the equation that have not been thought of. Why bother +introducing a rube goldberg machine like voting when a simple 8mb cap +with predictable growth gets the job done, potentially permanently? + + +On 6/23/2015 9:43 PM, odinn wrote: +> -----BEGIN PGP SIGNED MESSAGE----- +> Hash: SHA1 +> +> 1) Hard fork not (necessarily) needed +> 2) See Garzik's BIP 100, better (this is not meant to say "superior to +> your stuff," but rather simply to say, "Better you should work with +> Garzik to implement BIP-100, that would be good") +> 3) See points 1 and 2 above +> 4) If still reading... changes should be (as you seem to have been +> trying to lean towards)... lean towards gradual change; hence, changes +> that would flow from this BIP would be better off oriented in a +> process that dies not require the "way you have done it." +> +> You did address that, to be fair - in your TODO, this link: +> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks +> +> contained the following link: +> +> http://gavinandresen.ninja/bigger-blocks-another-way +> +> However, in reading that, I didn't see any meaningful statements that +> would refute the approach in Garzik's BIP-100. +> +> Maybe a better way to say this is, +> +> Work with Jeff Garzik (which I am sure you are already having such +> discussions in private) as well as the list discussions, +> Move forward on BIP-100 with Garzik and other developers (not such a +> bad plan really) and don't get caught up in XT. (If you feel you can +> develop XT further, that is your thing but it would perhaps make you +> lose focus, work together with other developers.) +> +> Relax into the process. Things will be ok. +> +> Respectfully, +> +> - -O +> +> On 06/22/2015 11:18 AM, Gavin Andresen wrote: +>> I promised to write a BIP after I'd implemented +>> increase-the-maximum-block-size code, so here it is. It also lives +>> at: +>> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki +>> +>> I don't expect any proposal to please everybody; there are +>> unavoidable tradeoffs to increasing the maximum block size. I +>> prioritize implementation simplicity -- it is hard to write +>> consensus-critical code, so simpler is better. +>> +>> +>> +>> +>> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen +>> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status: +>> Draft Type: Standards Track Created: 2015-06-22 +>> +>> ==Abstract== +>> +>> This BIP proposes replacing the fixed one megabyte maximum block +>> size with a maximum size that grows over time at a predictable +>> rate. +>> +>> ==Motivation== +>> +>> Transaction volume on the Bitcoin network has been growing, and +>> will soon reach the one-megabyte-every-ten-minutes limit imposed by +>> the one megabyte maximum block size. Increasing the maximum size +>> reduces the impact of that limit on Bitcoin adoption and growth. +>> +>> ==Specification== +>> +>> After deployment on the network (see the Deployment section for +>> details), the maximum allowed size of a block on the main network +>> shall be calculated based on the timestamp in the block header. +>> +>> The maximum size shall be 8,000,000 bytes at a timestamp of +>> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double +>> every 63,072,000 seconds (two years, ignoring leap years), until +>> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of +>> blocks in between doublings will increase linearly based on the +>> block's timestamp. The maximum size of blocks after 2036-01-06 +>> 00:00:00 UTC shall be 8,192,000,000 bytes. +>> +>> Expressed in pseudo-code, using integer math: +>> +>> function max_block_size(block_timestamp): +>> +>> time_start = 1452470400 time_double = 60*60*24*365*2 size_start = +>> 8000000 if block_timestamp >= time_start+time_double*10 return +>> size_start * 2^10 +>> +>> // Piecewise-linear-between-doublings growth: time_delta = +>> block_timestamp - t_start doublings = time_delta / time_double +>> remainder = time_delta % time_double interpolate = (size_start * +>> 2^doublings * remainder) / time_double max_size = size_start * +>> 2^doublings + interpolate +>> +>> return max_size +>> +>> ==Deployment== +>> +>> Deployment shall be controlled by hash-power supermajority vote +>> (similar to the technique used in BIP34), but the earliest possible +>> activation time is 2016-01-11 00:00:00 UTC. +>> +>> Activation is achieved when 750 of 1,000 consecutive blocks in the +>> best chain have a version number with bits 3 and 14 set (0x20000004 +>> in hex). The activation time will be the timestamp of the 750'th +>> block plus a two week (1,209,600 second) grace period to give any +>> remaining miners or services time to upgrade to support larger +>> blocks. If a supermajority is achieved more than two weeks before +>> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11 +>> 00:00:00 UTC. +>> +>> Block version numbers are used only for activation; once activation +>> is achieved, the maximum block size shall be as described in the +>> specification section, regardless of the version number of the +>> block. +>> +>> +>> ==Rationale== +>> +>> The initial size of 8,000,000 bytes was chosen after testing the +>> current reference implementation code with larger block sizes and +>> receiving feedback from miners stuck behind bandwidth-constrained +>> networks (in particular, Chinese miners behind the Great Firewall +>> of China). +>> +>> The doubling interval was chosen based on long-term growth trends +>> for CPU power, storage, and Internet bandwidth. The 20-year limit +>> was chosen because exponential growth cannot continue forever. +>> +>> Calculations are based on timestamps and not blockchain height +>> because a timestamp is part of every block's header. This allows +>> implementations to know a block's maximum size after they have +>> downloaded it's header, but before downloading any transactions. +>> +>> The deployment plan is taken from Jeff Garzik's proposed BIP100 +>> block size increase, and is designed to give miners, merchants, +>> and full-node-running-end-users sufficient time to upgrade to +>> software that supports bigger blocks. A 75% supermajority was +>> chosen so that one large mining pool does not have effective veto +>> power over a blocksize increase. The version number scheme is +>> designed to be compatible with Pieter's Wuille's proposed "Version +>> bits" BIP. +>> +>> TODO: summarize objections/arguments from +>> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks. +>> +>> TODO: describe other proposals and their advantages/disadvantages +>> over this proposal. +>> +>> +>> ==Compatibility== +>> +>> This is a hard-forking change to the Bitcoin protocol; anybody +>> running code that fully validates blocks must upgrade before the +>> activation time or they will risk rejecting a chain containing +>> larger-than-one-megabyte blocks. +>> +>> Simplified Payment Verification software is not affected, unless +>> it makes assumptions about the maximum depth of a transaction's +>> merkle branch based on the minimum size of a transaction and the +>> maximum block size. +>> +>> ==Implementation== +>> +>> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork +>> +>> +>> +>> _______________________________________________ bitcoin-dev mailing +>> list bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> +> - -- +> 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 +> +> iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175 +> Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+ +> K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw +> OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN +> fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s +> CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo= +> =ft62 +> -----END PGP SIGNATURE----- +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + |