But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period. On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote: > It is in their individual interests when the larger block that is allowed > for them grants them more fees. > > On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > When discussing this with Matt Whitlock earlier we basically concluded the > > block size will never increase under this proposal do to a collective > > action problem. If a miner votes for an increase and nobody else does, the > > blocksize will not increase yet he will still have to pay the difficulty > > penalty. > > > > It may be in everyone's collective interest to raise the block size but > > not their individual interest. > > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > >> With this proposal, how much would it cost a miner to include an 'extra' > >> 500-byte transaction if the average block size is 900K and it costs the > >> miner 20BTC in electricity/capital/etc to mine a block? > >> > >> If my understanding of the proposal is correct, it is: > >> > >> 500/900000 * 20 = 0.11111 BTC > >> > >> ... Or $2.50 at today's exchange rate. > >> > >> That seems excessive. > >> > >> -- > >> Gavin Andresen > >> > >> > >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev < > >> bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > > >> > This is the best proposal I've seen yet. Allow me to summarize: > >> > > >> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling > >> their block-size votes. > >> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly > >> trying to predict future market needs versus future technological > >> capacities. > >> > • It avoids a large step discontinuity in the block-size limit by > >> starting with a 1-MB limit. > >> > • It throttles changes to ±10% every 2016 blocks. > >> > • It imposes a tangible cost (higher difficulty) on miners who vote to > >> raise the block-size limit. > >> > • It avoids incentivizing miners to vote to lower the block-size limit. > >> > > >> > However, this proposal currently fails to answer a very important > >> question: > >> > > >> > • What is the mechanism for activation of the new consensus rule? It is > >> when a certain percentage of the blocks mined in a 2016-block retargeting > >> period contain valid block-size votes? > >> > > >> > > >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki > >> > > >> > > >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote: > >> >> Pull request: https://github.com/bitcoin/bips/pull/187 > >> > _______________________________________________ > >> > bitcoin-dev mailing list > >> > bitcoin-dev@lists.linuxfoundation.org > >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
