<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 &quot;soft&quot; 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">&lt;<a href="mailto:will.madden@novauri.com" target="_blank">will.madden@novauri.com</a>&gt;</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 &#39;BV&#39;+BlockSizeRequestValue into coinbase<br>
scriptSig, e.g. &quot;/BV8000000/&quot; 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 &quot;/BV5000000/&quot; for 20% of blocks and<br>
&quot;/BV5000001/&quot; for the remaining 10%.  If others don&#39;t consistently vote<br>
for the same &quot;/BV#/&quot; value, vote too consistently and have their value<br>
thrown out as the top 20%, I could win the resize to half capacity<br>
&quot;/BV5000001/&quot; 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>
&gt; -----BEGIN PGP SIGNED MESSAGE-----<br>
&gt; Hash: SHA1<br>
&gt;<br>
&gt; 1) Hard fork not (necessarily) needed<br>
&gt; 2) See Garzik&#39;s BIP 100, better (this is not meant to say &quot;superior to<br>
&gt; your stuff,&quot; but rather simply to say, &quot;Better you should work with<br>
&gt; Garzik to implement BIP-100, that would be good&quot;)<br>
&gt; 3) See points 1 and 2 above<br>
&gt; 4) If still reading... changes should be (as you seem to have been<br>
&gt; trying to lean towards)... lean towards gradual change; hence, changes<br>
&gt; that would flow from this BIP would be better off oriented in a<br>
&gt; process that dies not require the &quot;way you have done it.&quot;<br>
&gt;<br>
&gt; You did address that, to be fair - in your TODO, this link:<br>
&gt; <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>
&gt;<br>
&gt; contained the following link:<br>
&gt;<br>
&gt; <a href="http://gavinandresen.ninja/bigger-blocks-another-way" rel="noreferrer" target="_blank">http://gavinandresen.ninja/bigger-blocks-another-way</a><br>
&gt;<br>
&gt; However, in reading that, I didn&#39;t see any meaningful statements that<br>
&gt; would refute the approach in Garzik&#39;s BIP-100.<br>
&gt;<br>
&gt; Maybe a better way to say this is,<br>
&gt;<br>
&gt; Work with Jeff Garzik (which I am sure you are already having such<br>
&gt; discussions in private) as well as the list discussions,<br>
&gt; Move forward on BIP-100 with Garzik and other developers (not such a<br>
&gt; bad plan really) and don&#39;t get caught up in XT.  (If you feel you can<br>
&gt; develop XT further, that is your thing but it would perhaps make you<br>
&gt; lose focus, work together with other developers.)<br>
&gt;<br>
&gt; Relax into the process.  Things will be ok.<br>
&gt;<br>
&gt; Respectfully,<br>
&gt;<br>
&gt; - -O<br>
&gt;<br>
&gt; On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br>
&gt;&gt; I promised to write a BIP after I&#39;d implemented<br>
&gt;&gt; increase-the-maximum-block-size code, so here it is. It also lives<br>
&gt;&gt; at:<br>
&gt;&gt; <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>
&gt;&gt;<br>
&gt;&gt;  I don&#39;t expect any proposal to please everybody; there are<br>
&gt;&gt; unavoidable tradeoffs to increasing the maximum block size. I<br>
&gt;&gt; prioritize implementation simplicity -- it is hard to write<br>
&gt;&gt; consensus-critical code, so simpler is better.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<br>
&gt;&gt; &lt;<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a> &lt;mailto:<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>&gt;&gt; Status:<br>
&gt;&gt; Draft Type: Standards Track Created: 2015-06-22<br>
&gt;&gt;<br>
&gt;&gt; ==Abstract==<br>
&gt;&gt;<br>
&gt;&gt; This BIP proposes replacing the fixed one megabyte maximum block<br>
&gt;&gt; size with a maximum size that grows over time at a predictable<br>
&gt;&gt; rate.<br>
&gt;&gt;<br>
&gt;&gt; ==Motivation==<br>
&gt;&gt;<br>
&gt;&gt; Transaction volume on the Bitcoin network has been growing, and<br>
&gt;&gt; will soon reach the one-megabyte-every-ten-minutes limit imposed by<br>
&gt;&gt; the one megabyte maximum block size. Increasing the maximum size<br>
&gt;&gt; reduces the impact of that limit on Bitcoin adoption and growth.<br>
&gt;&gt;<br>
&gt;&gt; ==Specification==<br>
&gt;&gt;<br>
&gt;&gt; After deployment on the network (see the Deployment section for<br>
&gt;&gt; details), the maximum allowed size of a block on the main network<br>
&gt;&gt; shall be calculated based on the timestamp in the block header.<br>
&gt;&gt;<br>
&gt;&gt; The maximum size shall be 8,000,000 bytes at a timestamp of<br>
&gt;&gt; 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<br>
&gt;&gt; every 63,072,000 seconds (two years, ignoring leap years), until<br>
&gt;&gt; 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of<br>
&gt;&gt; blocks in between doublings will increase linearly based on the<br>
&gt;&gt; block&#39;s timestamp. The maximum size of blocks after 2036-01-06<br>
&gt;&gt; 00:00:00 UTC shall be 8,192,000,000 bytes.<br>
&gt;&gt;<br>
&gt;&gt; Expressed in pseudo-code, using integer math:<br>
&gt;&gt;<br>
&gt;&gt; function max_block_size(block_timestamp):<br>
&gt;&gt;<br>
&gt;&gt; time_start = 1452470400 time_double = 60*60*24*365*2 size_start =<br>
&gt;&gt; 8000000 if block_timestamp &gt;= time_start+time_double*10 return<br>
&gt;&gt; size_start * 2^10<br>
&gt;&gt;<br>
&gt;&gt; // Piecewise-linear-between-doublings growth: time_delta =<br>
&gt;&gt; block_timestamp - t_start doublings = time_delta / time_double<br>
&gt;&gt; remainder = time_delta % time_double interpolate = (size_start *<br>
&gt;&gt; 2^doublings * remainder) / time_double max_size = size_start *<br>
&gt;&gt; 2^doublings + interpolate<br>
&gt;&gt;<br>
&gt;&gt; return max_size<br>
&gt;&gt;<br>
&gt;&gt; ==Deployment==<br>
&gt;&gt;<br>
&gt;&gt; Deployment shall be controlled by hash-power supermajority vote<br>
&gt;&gt; (similar to the technique used in BIP34), but the earliest possible<br>
&gt;&gt; activation time is 2016-01-11 00:00:00 UTC.<br>
&gt;&gt;<br>
&gt;&gt; Activation is achieved when 750 of 1,000 consecutive blocks in the<br>
&gt;&gt; best chain have a version number with bits 3 and 14 set (0x20000004<br>
&gt;&gt; in hex). The activation time will be the timestamp of the 750&#39;th<br>
&gt;&gt; block plus a two week (1,209,600 second) grace period to give any<br>
&gt;&gt; remaining miners or services time to upgrade to support larger<br>
&gt;&gt; blocks. If a supermajority is achieved more than two weeks before<br>
&gt;&gt; 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br>
&gt;&gt; 00:00:00 UTC.<br>
&gt;&gt;<br>
&gt;&gt; Block version numbers are used only for activation; once activation<br>
&gt;&gt; is achieved, the maximum block size shall be as described in the<br>
&gt;&gt; specification section, regardless of the version number of the<br>
&gt;&gt; block.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ==Rationale==<br>
&gt;&gt;<br>
&gt;&gt; The initial size of 8,000,000 bytes was chosen after testing the<br>
&gt;&gt; current reference implementation code with larger block sizes and<br>
&gt;&gt; receiving feedback from miners stuck behind bandwidth-constrained<br>
&gt;&gt; networks (in particular, Chinese miners behind the Great Firewall<br>
&gt;&gt; of China).<br>
&gt;&gt;<br>
&gt;&gt; The doubling interval was chosen based on long-term growth trends<br>
&gt;&gt; for CPU power, storage, and Internet bandwidth. The 20-year limit<br>
&gt;&gt; was chosen because exponential growth cannot continue forever.<br>
&gt;&gt;<br>
&gt;&gt; Calculations are based on timestamps and not blockchain height<br>
&gt;&gt; because a timestamp is part of every block&#39;s header. This allows<br>
&gt;&gt; implementations to know a block&#39;s maximum size after they have<br>
&gt;&gt; downloaded it&#39;s header, but before downloading any transactions.<br>
&gt;&gt;<br>
&gt;&gt; The deployment plan is taken from Jeff Garzik&#39;s proposed BIP100<br>
&gt;&gt; block size increase, and is designed to give miners, merchants,<br>
&gt;&gt; and full-node-running-end-users sufficient time to upgrade to<br>
&gt;&gt; software that supports bigger blocks. A 75% supermajority was<br>
&gt;&gt; chosen so that one large mining pool does not have effective veto<br>
&gt;&gt; power over a blocksize increase. The version number scheme is<br>
&gt;&gt; designed to be compatible with Pieter&#39;s Wuille&#39;s proposed &quot;Version<br>
&gt;&gt; bits&quot; BIP.<br>
&gt;&gt;<br>
&gt;&gt; TODO: summarize objections/arguments from<br>
&gt;&gt; <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>
&gt;&gt;<br>
&gt;&gt; TODO: describe other proposals and their advantages/disadvantages<br>
&gt;&gt; over this proposal.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ==Compatibility==<br>
&gt;&gt;<br>
&gt;&gt; This is a hard-forking change to the Bitcoin protocol; anybody<br>
&gt;&gt; running code that fully validates blocks must upgrade before the<br>
&gt;&gt; activation time or they will risk rejecting a chain containing<br>
&gt;&gt; larger-than-one-megabyte blocks.<br>
&gt;&gt;<br>
&gt;&gt; Simplified Payment Verification software is not affected, unless<br>
&gt;&gt; it makes assumptions about the maximum depth of a transaction&#39;s<br>
&gt;&gt; merkle branch based on the minimum size of a transaction and the<br>
&gt;&gt; maximum block size.<br>
&gt;&gt;<br>
&gt;&gt; ==Implementation==<br>
&gt;&gt;<br>
&gt;&gt; <a href="https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork" rel="noreferrer" target="_blank">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________ bitcoin-dev mailing<br>
&gt;&gt; list <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt;&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;&gt;<br>
&gt;<br>
&gt; - --<br>
&gt; <a href="http://abis.io" rel="noreferrer" target="_blank">http://abis.io</a> ~<br>
&gt; &quot;a protocol concept to enable decentralization<br>
&gt; and expansion of a giving economy, and a new social good&quot;<br>
&gt; <a href="https://keybase.io/odinn" rel="noreferrer" target="_blank">https://keybase.io/odinn</a><br>
&gt; -----BEGIN PGP SIGNATURE-----<br>
&gt; Version: GnuPG v1<br>
&gt;<br>
&gt; iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br>
&gt; Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+<br>
&gt; K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br>
&gt; OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br>
&gt; fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s<br>
&gt; CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=<br>
&gt; =ft62<br>
&gt; -----END PGP SIGNATURE-----<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
&gt;<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>