60% of the hashrate can easily agree to force a softfork which reduces the block size. As soon as the fork occurs, there is a very strong incentive for all the remaining 40% to go along with it: if they don't, they're mining worthless blocks.
They can use a BIP-34 style mechanism to trigger the fork so there's negligible risk to the miners. On Wed, Jun 24, 2015 at 10:23:18AM -0700, Raystonn wrote: > <p dir="ltr">You really believe they would risk getting orphaned by skipping > the longer chain, just to attempt to reduce average block size? No, that > doesn't happen today. Laziness in leaving the default size is common. But > that is not collusion, nor an attempt to manipulate the block sizes of other > miners.<br> > </p> > <div class="gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach > <[email protected]> wrote:<br type='attribution'><blockquote > class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc > solid;padding-left:1ex"><p dir="ltr">They do so by not building on larger > blocks</p> > <div class="elided-text">On Jun 23, 2015 9:31 PM, "Raystonn" <<a > href="mailto:raystonn@hotmail.com";>raystonn@hotmail.com</a>> > wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc > solid;padding-left:1ex"><p dir="ltr">No, they can lower their own block > sizes.?? But they cannot currently lower the sizes of blocks mined by > others.?? That is not the same thing by any stretch of the imagination.</p> > <div class="elided-text">On 23 Jun 2015 8:50 pm, Jeff Garzik <<a > href="mailto:jgarzik@gmail.com";>jgarzik@gmail.com</a>> wrote:<br > /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc > solid;padding-left:1ex"><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><br /><div>On Tue, Jun 23, 2015 at 8:05 > PM, William Madden <span dir="ltr"><<a > href="mailto:will.madden@novauri.com";>will.madden@novauri.com</a>></span> > wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc > solid;padding-left:1 ex">Here are refutations of the approach in BIP-100 here:<br /> > <a > href="http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf";>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><div><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";>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";>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";>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";>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";>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";>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br > /> > >><br /> > ><br /> > > - --<br /> > > <a href="http://abis.io";>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";>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";>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";>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br > /> > </div></div></blockquote></div><br /></div> > </blockquote></div><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";>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br > /> > <br /></blockquote></div> > </blockquote></div> > _______________________________________________ > bitcoin-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
