<div dir="ltr">Miners can collude today to lower the block size limit.<div><br></div><div>In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: <a href="http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block</a></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 23, 2015 at 8:05 PM, William Madden <span dir="ltr"><<a href="mailto:will.madden@novauri.com" target="_blank">will.madden@novauri.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here are refutations of the approach in BIP-100 here:<br>
<a href="http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf" rel="noreferrer" target="_blank">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf</a><br>
<br>
To recap BIP-100:<br>
<br>
1) Hard form to remove static 1MB block size limit<br>
2) Add new floating block size limit set to 1MB<br>
3) Historical 32MB message limit remains<br>
4) Hard form on testnet 9/1/2015<br>
5) Hard form on main 1/11/2016<br>
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br>
threshold by 90% of blocks<br>
7) Limit increase or decrease may not exceed 2x in any one step<br>
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase<br>
scriptSig, e.g. "/BV8000000/" to vote for 8M.<br>
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<br>
most common floor (minimum) is chosen.<br>
<br>
8MB limits doubling just under every 2 years makes a static value grow<br>
in a predictable manner.<br>
<br>
BIP-100 makes a static value grow (or more importantly potentially<br>
shrink) in an unpredictable manner based on voting mechanics that are<br>
untested in this capacity in the bitcoin network. Introducing a highly<br>
variable and untested dynamic into an already complex system is<br>
unnecessarily risky.<br>
<br>
For example, the largely arbitrary voting rules listed in 9 above can be<br>
gamed. If I control pools or have affiliates involved in pools that<br>
mine slightly more than 20% of blocks, I could wait until block sizes<br>
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and<br>
"/BV5000001/" for the remaining 10%. If others don't consistently vote<br>
for the same "/BV#/" value, vote too consistently and have their value<br>
thrown out as the top 20%, I could win the resize to half capacity<br>
"/BV5000001/" because it was the lowest repeated value not in the bottom<br>
20%.<br>
<br>
I could use this to force an exodus to my sidechain/alt coin, or to<br>
choke out the bitcoin network. A first improvement would be to only let<br>
BIP-100 raise the cap and not lower it, but if I can think of a<br>
vulnerability off the top of my head, there will be others on the other<br>
side of the equation that have not been thought of. Why bother<br>
introducing a rube goldberg machine like voting when a simple 8mb cap<br>
with predictable growth gets the job done, potentially permanently?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 6/23/2015 9:43 PM, odinn wrote:<br>
> -----BEGIN PGP SIGNED MESSAGE-----<br>
> Hash: SHA1<br>
><br>
> 1) Hard fork not (necessarily) needed<br>
> 2) See Garzik's BIP 100, better (this is not meant to say "superior to<br>
> your stuff," but rather simply to say, "Better you should work with<br>
> Garzik to implement BIP-100, that would be good")<br>
> 3) See points 1 and 2 above<br>
> 4) If still reading... changes should be (as you seem to have been<br>
> trying to lean towards)... lean towards gradual change; hence, changes<br>
> that would flow from this BIP would be better off oriented in a<br>
> process that dies not require the "way you have done it."<br>
><br>
> You did address that, to be fair - in your TODO, this link:<br>
> <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks" rel="noreferrer" target="_blank">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><br>
><br>
> contained the following link:<br>
><br>
> <a href="http://gavinandresen.ninja/bigger-blocks-another-way" rel="noreferrer" target="_blank">http://gavinandresen.ninja/bigger-blocks-another-way</a><br>
><br>
> However, in reading that, I didn't see any meaningful statements that<br>
> would refute the approach in Garzik's BIP-100.<br>
><br>
> Maybe a better way to say this is,<br>
><br>
> Work with Jeff Garzik (which I am sure you are already having such<br>
> discussions in private) as well as the list discussions,<br>
> Move forward on BIP-100 with Garzik and other developers (not such a<br>
> bad plan really) and don't get caught up in XT. (If you feel you can<br>
> develop XT further, that is your thing but it would perhaps make you<br>
> lose focus, work together with other developers.)<br>
><br>
> Relax into the process. Things will be ok.<br>
><br>
> Respectfully,<br>
><br>
> - -O<br>
><br>
> On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br>
>> I promised to write a BIP after I'd implemented<br>
>> increase-the-maximum-block-size code, so here it is. It also lives<br>
>> at:<br>
>> <a href="https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki" rel="noreferrer" target="_blank">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki</a><br>
>><br>
>> I don't expect any proposal to please everybody; there are<br>
>> unavoidable tradeoffs to increasing the maximum block size. I<br>
>> prioritize implementation simplicity -- it is hard to write<br>
>> consensus-critical code, so simpler is better.<br>
>><br>
>><br>
>><br>
>><br>
>> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<br>
>> <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a> <mailto:<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>>> Status:<br>
>> Draft Type: Standards Track Created: 2015-06-22<br>
>><br>
>> ==Abstract==<br>
>><br>
>> This BIP proposes replacing the fixed one megabyte maximum block<br>
>> size with a maximum size that grows over time at a predictable<br>
>> rate.<br>
>><br>
>> ==Motivation==<br>
>><br>
>> Transaction volume on the Bitcoin network has been growing, and<br>
>> will soon reach the one-megabyte-every-ten-minutes limit imposed by<br>
>> the one megabyte maximum block size. Increasing the maximum size<br>
>> reduces the impact of that limit on Bitcoin adoption and growth.<br>
>><br>
>> ==Specification==<br>
>><br>
>> After deployment on the network (see the Deployment section for<br>
>> details), the maximum allowed size of a block on the main network<br>
>> shall be calculated based on the timestamp in the block header.<br>
>><br>
>> The maximum size shall be 8,000,000 bytes at a timestamp of<br>
>> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<br>
>> every 63,072,000 seconds (two years, ignoring leap years), until<br>
>> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of<br>
>> blocks in between doublings will increase linearly based on the<br>
>> block's timestamp. The maximum size of blocks after 2036-01-06<br>
>> 00:00:00 UTC shall be 8,192,000,000 bytes.<br>
>><br>
>> Expressed in pseudo-code, using integer math:<br>
>><br>
>> function max_block_size(block_timestamp):<br>
>><br>
>> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =<br>
>> 8000000 if block_timestamp >= time_start+time_double*10 return<br>
>> size_start * 2^10<br>
>><br>
>> // Piecewise-linear-between-doublings growth: time_delta =<br>
>> block_timestamp - t_start doublings = time_delta / time_double<br>
>> remainder = time_delta % time_double interpolate = (size_start *<br>
>> 2^doublings * remainder) / time_double max_size = size_start *<br>
>> 2^doublings + interpolate<br>
>><br>
>> return max_size<br>
>><br>
>> ==Deployment==<br>
>><br>
>> Deployment shall be controlled by hash-power supermajority vote<br>
>> (similar to the technique used in BIP34), but the earliest possible<br>
>> activation time is 2016-01-11 00:00:00 UTC.<br>
>><br>
>> Activation is achieved when 750 of 1,000 consecutive blocks in the<br>
>> best chain have a version number with bits 3 and 14 set (0x20000004<br>
>> in hex). The activation time will be the timestamp of the 750'th<br>
>> block plus a two week (1,209,600 second) grace period to give any<br>
>> remaining miners or services time to upgrade to support larger<br>
>> blocks. If a supermajority is achieved more than two weeks before<br>
>> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br>
>> 00:00:00 UTC.<br>
>><br>
>> Block version numbers are used only for activation; once activation<br>
>> is achieved, the maximum block size shall be as described in the<br>
>> specification section, regardless of the version number of the<br>
>> block.<br>
>><br>
>><br>
>> ==Rationale==<br>
>><br>
>> The initial size of 8,000,000 bytes was chosen after testing the<br>
>> current reference implementation code with larger block sizes and<br>
>> receiving feedback from miners stuck behind bandwidth-constrained<br>
>> networks (in particular, Chinese miners behind the Great Firewall<br>
>> of China).<br>
>><br>
>> The doubling interval was chosen based on long-term growth trends<br>
>> for CPU power, storage, and Internet bandwidth. The 20-year limit<br>
>> was chosen because exponential growth cannot continue forever.<br>
>><br>
>> Calculations are based on timestamps and not blockchain height<br>
>> because a timestamp is part of every block's header. This allows<br>
>> implementations to know a block's maximum size after they have<br>
>> downloaded it's header, but before downloading any transactions.<br>
>><br>
>> The deployment plan is taken from Jeff Garzik's proposed BIP100<br>
>> block size increase, and is designed to give miners, merchants,<br>
>> and full-node-running-end-users sufficient time to upgrade to<br>
>> software that supports bigger blocks. A 75% supermajority was<br>
>> chosen so that one large mining pool does not have effective veto<br>
>> power over a blocksize increase. The version number scheme is<br>
>> designed to be compatible with Pieter's Wuille's proposed "Version<br>
>> bits" BIP.<br>
>><br>
>> TODO: summarize objections/arguments from<br>
>> <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks" rel="noreferrer" target="_blank">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a>.<br>
>><br>
>> TODO: describe other proposals and their advantages/disadvantages<br>
>> over this proposal.<br>
>><br>
>><br>
>> ==Compatibility==<br>
>><br>
>> This is a hard-forking change to the Bitcoin protocol; anybody<br>
>> running code that fully validates blocks must upgrade before the<br>
>> activation time or they will risk rejecting a chain containing<br>
>> larger-than-one-megabyte blocks.<br>
>><br>
>> Simplified Payment Verification software is not affected, unless<br>
>> it makes assumptions about the maximum depth of a transaction's<br>
>> merkle branch based on the minimum size of a transaction and the<br>
>> maximum block size.<br>
>><br>
>> ==Implementation==<br>
>><br>
>> <a href="https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork" rel="noreferrer" target="_blank">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________ bitcoin-dev mailing<br>
>> list <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
>> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
>><br>
><br>
> - --<br>
> <a href="http://abis.io" rel="noreferrer" target="_blank">http://abis.io</a> ~<br>
> "a protocol concept to enable decentralization<br>
> and expansion of a giving economy, and a new social good"<br>
> <a href="https://keybase.io/odinn" rel="noreferrer" target="_blank">https://keybase.io/odinn</a><br>
> -----BEGIN PGP SIGNATURE-----<br>
> Version: GnuPG v1<br>
><br>
> iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br>
> Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br>
> K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br>
> OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br>
> fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br>
> CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=<br>
> =ft62<br>
> -----END PGP SIGNATURE-----<br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div></div></blockquote></div><br></div>