* [bitcoin-dev] Consensus based block size retargeting algorithm (draft) @ 2015-08-21 22:22 Btc Drak 2015-08-21 23:17 ` Paul Sztorc 2015-08-22 0:06 ` Ahmed Zsales 0 siblings, 2 replies; 26+ messages in thread From: Btc Drak @ 2015-08-21 22:22 UTC (permalink / raw) To: Bitcoin Dev I wanted to offer a potential way to adjust the block size limit in a democratic way without making it easy to game. This is meant only as a starting point for a general idea. Thresholds and exact figures and the details of the algorithm are up for debate, and possibly some formula based determination. The living document is currently a gist available at https://gist.github.com/btcdrak/1c3a323100a912b605b5 <pre> BIP: XX Title: Consensus based block size retargeting algorithm Author: BtcDrak <btcdrak@gmail•com> Status: Draft Type: Standards Track Created: 2015-08-21 </pre> ==Abstract== A method of altering the maximum allowed block size of the Bitcoin protocol using a consensus based approach. ==Motivation== There is a perception that Bitcoin cannot easily respond to raising the blocksize limit if popularity was to suddenly increase due to a mass adoption curve, because co-ordinating a hard fork takes considerable time, and being unable to respond in a timely manner would irreparably harm the credibility of bitcoin. Additionally, predetermined block size increases are problematic because they attempt to predict the future, and if too large could have unintended consequences like damaging the possibility for a fee market to develop as block subsidy decreases substantially over the next 9 years; introducing or exacerbating mining attack vectors; or somehow affect the network in unknown or unpredicted ways. Since fixed changes are hard to deploy, the damage could be extensive. Dynamic block size adjustments also suffer from the potential to be gamed by the larger hash power. ==Rationale== By introducing a cost to increase the block size ensures the mining community will collude to increase it only when there is a clear necessity, and reduce it when it is unnecessary. Rogue miners cannot force their wishes so easily because not only will they have to pay extra a difficulty target, then can be downvoted at no cost by the objecting hash power. ==Specification== The initial "base block size limit" shall be 1MB. Miners can vote for a block size increase by signalling the proposed percentage increase of the "base block size limit" in the coinbase field. For the vote to be considered valid the block they mine must meets a difficulty target which is proportionally larger than the standard difficulty target based on the percentage increase they voted for. If a miner does not vote, or the vote is invalid, it shall be counted as a vote for no change. Miners may vote the size down by signalling in the coinbase field without paying a difficulty penalty. Every 2016 blocks, the maximum allowed block size will be recalculated by the average of all votes in the last 2016 blocks, i.e. sum each vote from each block and divide by 2016 then multiply by the base block size limit. This will redefine the base block size limit for the next 2016 blocks. Blocks that are larger than the calculated base block size limit are invalid and MUST be rejected. The maximum change up or down each retargeting period shall be limited to 10% of the base block size limit. The maximum block size may not increase above 8MB. Votes shall be cast by adding the following human readable multiplier to the coinbase string “/BXn.nnn/” where valid votes would exist between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10% increase). “/BX1.000/” would be a vote for no change. Invalid votes will be counted as a vote for no change: “/BX1.000/”. ==Acknowledgements== This proposal is based on ideas and concepts derived from the writings of Meni Rosenfeld and Gregory Maxwell. ==Copyright== This work is placed in the public domain. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak @ 2015-08-21 23:17 ` Paul Sztorc 2015-08-22 0:06 ` Ahmed Zsales 1 sibling, 0 replies; 26+ messages in thread From: Paul Sztorc @ 2015-08-21 23:17 UTC (permalink / raw) To: Btc Drak, Bitcoin Dev You said: > There is a perception that Bitcoin cannot easily respond to raising the blocksize limit if popularity was to suddenly increase From this, my understanding is that you are operating on the principle that "the optimum blocksize" is related to "popularity/use of Bitcoin". It seems that others on this list instead feel that "the optimum blocksize" is a function of "technical limitations (namely bandwidth)". Do you acknowledge this as an irreconcilable difference in approach? Also, I'm not sure, but your principle would seem to imply that "outsourcing the decision to Miners" is superfluous. You are concerned (according to you) with "not reacting to 'popularity' quickly enough", and you are only against "predetermined increases" and "hashpower influences" (according to you), so why not measure "popularity" directly (by using "transaction volume" or "fees paid") and use that number to set the blocksize? -- However, thank you very much for actually stating a principle. Unless one knows what a person's principle is, one *can't even check if* what they are saying makes any sense (according to *them*), so my completely sincere congratulations on an intelligible email. On 8/21/2015 6:22 PM, Btc Drak via bitcoin-dev wrote: > I wanted to offer a potential way to adjust the block size limit in a > democratic way without making it easy to game. This is meant only as a > starting point for a general idea. Thresholds and exact figures and > the details of the algorithm are up for debate, and possibly some > formula based determination. > > The living document is currently a gist available at > https://gist.github.com/btcdrak/1c3a323100a912b605b5 > > > <pre> > BIP: XX > Title: Consensus based block size retargeting algorithm > Author: BtcDrak <btcdrak@gmail•com> > Status: Draft > Type: Standards Track > Created: 2015-08-21 > </pre> > > ==Abstract== > > A method of altering the maximum allowed block size of the Bitcoin > protocol using a consensus based approach. > > ==Motivation== > > There is a perception that Bitcoin cannot easily respond to raising > the blocksize limit if popularity was to suddenly increase due to a > mass adoption curve, because co-ordinating a hard fork takes > considerable time, and being unable to respond in a timely manner > would irreparably harm the credibility of bitcoin. > > Additionally, predetermined block size increases are problematic > because they attempt to predict the future, and if too large could > have unintended consequences like damaging the possibility for a fee > market to develop as block subsidy decreases substantially over the > next 9 years; introducing or exacerbating mining attack vectors; or > somehow affect the network in unknown or unpredicted ways. Since fixed > changes are hard to deploy, the damage could be extensive. > > Dynamic block size adjustments also suffer from the potential to be > gamed by the larger hash power. > > > ==Rationale== > > By introducing a cost to increase the block size ensures the mining > community will collude to increase it only when there is a clear > necessity, and reduce it when it is unnecessary. Rogue miners cannot > force their wishes so easily because not only will they have to pay > extra a difficulty target, then can be downvoted at no cost by the > objecting hash power. > > > ==Specification== > > The initial "base block size limit" shall be 1MB. > > Miners can vote for a block size increase by signalling the proposed > percentage increase of the "base block size limit" in the coinbase > field. For the vote to be considered valid the block they mine must > meets a difficulty target which is proportionally larger than the > standard difficulty target based on the percentage increase they voted > for. If a miner does not vote, or the vote is invalid, it shall be > counted as a vote for no change. > > Miners may vote the size down by signalling in the coinbase field > without paying a difficulty penalty. > > Every 2016 blocks, the maximum allowed block size will be recalculated > by the average of all votes in the last 2016 blocks, i.e. sum each > vote from each block and divide by 2016 then multiply by the base > block size limit. This will redefine the base block size limit for the > next 2016 blocks. > > Blocks that are larger than the calculated base block size limit are > invalid and MUST be rejected. > > The maximum change up or down each retargeting period shall be limited > to 10% of the base block size limit. > > The maximum block size may not increase above 8MB. > > Votes shall be cast by adding the following human readable multiplier > to the coinbase string “/BXn.nnn/” where valid votes would exist > between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10% > increase). “/BX1.000/” would be a vote for no change. Invalid votes > will be counted as a vote for no change: “/BX1.000/”. > > > ==Acknowledgements== > > This proposal is based on ideas and concepts derived from the writings > of Meni Rosenfeld and Gregory Maxwell. > > > ==Copyright== > > This work is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak 2015-08-21 23:17 ` Paul Sztorc @ 2015-08-22 0:06 ` Ahmed Zsales 2015-08-28 20:28 ` Btc Drak 1 sibling, 1 reply; 26+ messages in thread From: Ahmed Zsales @ 2015-08-22 0:06 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5515 bytes --] Interesting. Unless I misunderstand the proposal, you would have to factor a way to deal with miner cartel behavior. A few emails every week and the larger miners could collude to set prices. With that figured, then your voting proposal could be triggered by a moving day block average which takes into account capacity for any given period, plus a level of headroom for unexpected spikes. The issue with this is forward planning is more important, especially when the moving average is longer than a week. Credit card providers and retailers use a number of factors to plan for capacity on a regional basis. From previous years figures, long-term weather forecasts, annual calendar events, one off events, etc. A global currency can't use many of these tools for forward planning. E.g. religious holidays are among the biggest events for transactions; if we take Christmas, your proposal could work out a capacity during a quiet period in November leading to a downward adjustment which then sees transactions getting maxed out during the two weeks before Christmas eve. You could then have an upward adjustment, but people stop spending on Christmas day. These are human factors that need to be considered. On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > I wanted to offer a potential way to adjust the block size limit in a > democratic way without making it easy to game. This is meant only as a > starting point for a general idea. Thresholds and exact figures and > the details of the algorithm are up for debate, and possibly some > formula based determination. > > The living document is currently a gist available at > https://gist.github.com/btcdrak/1c3a323100a912b605b5 > > > <pre> > BIP: XX > Title: Consensus based block size retargeting algorithm > Author: BtcDrak <btcdrak@gmail•com> > Status: Draft > Type: Standards Track > Created: 2015-08-21 > </pre> > > ==Abstract== > > A method of altering the maximum allowed block size of the Bitcoin > protocol using a consensus based approach. > > ==Motivation== > > There is a perception that Bitcoin cannot easily respond to raising > the blocksize limit if popularity was to suddenly increase due to a > mass adoption curve, because co-ordinating a hard fork takes > considerable time, and being unable to respond in a timely manner > would irreparably harm the credibility of bitcoin. > > Additionally, predetermined block size increases are problematic > because they attempt to predict the future, and if too large could > have unintended consequences like damaging the possibility for a fee > market to develop as block subsidy decreases substantially over the > next 9 years; introducing or exacerbating mining attack vectors; or > somehow affect the network in unknown or unpredicted ways. Since fixed > changes are hard to deploy, the damage could be extensive. > > Dynamic block size adjustments also suffer from the potential to be > gamed by the larger hash power. > > > ==Rationale== > > By introducing a cost to increase the block size ensures the mining > community will collude to increase it only when there is a clear > necessity, and reduce it when it is unnecessary. Rogue miners cannot > force their wishes so easily because not only will they have to pay > extra a difficulty target, then can be downvoted at no cost by the > objecting hash power. > > > ==Specification== > > The initial "base block size limit" shall be 1MB. > > Miners can vote for a block size increase by signalling the proposed > percentage increase of the "base block size limit" in the coinbase > field. For the vote to be considered valid the block they mine must > meets a difficulty target which is proportionally larger than the > standard difficulty target based on the percentage increase they voted > for. If a miner does not vote, or the vote is invalid, it shall be > counted as a vote for no change. > > Miners may vote the size down by signalling in the coinbase field > without paying a difficulty penalty. > > Every 2016 blocks, the maximum allowed block size will be recalculated > by the average of all votes in the last 2016 blocks, i.e. sum each > vote from each block and divide by 2016 then multiply by the base > block size limit. This will redefine the base block size limit for the > next 2016 blocks. > > Blocks that are larger than the calculated base block size limit are > invalid and MUST be rejected. > > The maximum change up or down each retargeting period shall be limited > to 10% of the base block size limit. > > The maximum block size may not increase above 8MB. > > Votes shall be cast by adding the following human readable multiplier > to the coinbase string “/BXn.nnn/” where valid votes would exist > between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10% > increase). “/BX1.000/” would be a vote for no change. Invalid votes > will be counted as a vote for no change: “/BX1.000/”. > > > ==Acknowledgements== > > This proposal is based on ideas and concepts derived from the writings > of Meni Rosenfeld and Gregory Maxwell. > > > ==Copyright== > > This work is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 6516 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-22 0:06 ` Ahmed Zsales @ 2015-08-28 20:28 ` Btc Drak 2015-08-28 21:15 ` Matt Whitlock 2015-08-29 9:38 ` jl2012 0 siblings, 2 replies; 26+ messages in thread From: Btc Drak @ 2015-08-28 20:28 UTC (permalink / raw) To: Ahmed Zsales; +Cc: Bitcoin Dev I have received a lot of feedback on the original gist[1], reddit[2], ML and IRC and have reworked the text somewhat. I also request the BIP maintainer for a BIP number assignment [1] https://gist.github.com/btcdrak/1c3a323100a912b605b5 [2] https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/ Pull request: https://github.com/bitcoin/bips/pull/187 <pre> BIP: XX Title: Consensus based block size retargeting algorithm Author: BtcDrak <btcdrak@gmail•com> Status: Draft Type: Standards Track Created: 2015-08-21 </pre> ==Abstract== A method of altering the maximum allowed block size of the Bitcoin protocol using a consensus based approach. ==Motivation== There is a belief that Bitcoin cannot easily respond to raising the blocksize limit if popularity was to suddenly increase due to a mass adoption curve, because co-ordinating a hard fork takes considerable time, and being unable to respond in a timely manner would irreparably harm the credibility of bitcoin. Additionally, predetermined block size increases are problematic because they attempt to predict the future, and if too large could have unintended consequences like damaging the possibility for a fee market to develop as block subsidy decreases substantially over the next 9 years; introducing or exacerbating mining attack vectors; or somehow affect the network in unknown or unpredicted ways. Since fixed changes are hard to deploy, the damage could be extensive. Dynamic block size adjustments also suffer from the potential to be gamed by the larger hash power. Free voting as suggested by BIP100 allows miners to sell their votes out of band at no risk, and enable the sponsor the ability to manipulate the blocksize. It also provides a cost free method or the larger pools to vote in ways to manipulate the blocksize such to disadvantage or attack smaller pools. ==Rationale== By introducing a cost to increase the block size ensures the mining community will collude to increase it only when there is a clear necessity, and reduce it when it is unnecessary. Larger miners cannot force their wishes so easily because not only will they have to pay extra a difficulty target, then can be downvoted at no cost by the objecting hash power. Using difficulty as a penalty is better than a fixed cost in bitcoins because it is less predictable. ==Specification== The initial block size limit shall be 1MB. Each time a miner creates a block, they may vote to increase or decrease the blocksize by a maximum of 10% of the current block size limit. These votes will be used to recalculate the new block size limit every 2016 blocks. Votes are cast using the block's coinbase field. The first 4 bytes of the coinbase field shall be repurposed for voting as an unsigned long integer which will be the block size in bytes. If a miner votes for an increase, the block hash must meet a difficulty target which is proportionally larger than the standard difficulty target based on the percentage increase they voted for. Votes proposing decreasing the block size limit do not need to meet a higher difficulty target. Miners can vote for no change by voting for the current block size. For blocks to be valid the blockhash must meet the required difficulty target for the vote otherwise the block is invalid and will be rejected. Every 2016 blocks, the block size limit will be recalculated by the median of all votes in the last 2016 blocks. This will redefine the block size limit for the next 2016 blocks. Blocks that are larger than the calculated base block size limit are invalid and will be rejected. The base block size limit may not reduce below 1MB. ==Acknowledgements== This proposal is based on ideas and concepts derived from the writings of Meni Rosenfeld and Gregory Maxwell. ==Copyright== This work is placed in the public domain. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 20:28 ` Btc Drak @ 2015-08-28 21:15 ` Matt Whitlock 2015-08-28 22:24 ` Gavin 2015-08-28 23:36 ` Btc Drak 2015-08-29 9:38 ` jl2012 1 sibling, 2 replies; 26+ messages in thread From: Matt Whitlock @ 2015-08-28 21:15 UTC (permalink / raw) To: bitcoin-dev, Btc Drak 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 21:15 ` Matt Whitlock @ 2015-08-28 22:24 ` Gavin 2015-08-28 23:35 ` Chris Pacia 2015-08-28 23:38 ` Btc Drak 2015-08-28 23:36 ` Btc Drak 1 sibling, 2 replies; 26+ messages in thread From: Gavin @ 2015-08-28 22:24 UTC (permalink / raw) To: Matt Whitlock; +Cc: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 22:24 ` Gavin @ 2015-08-28 23:35 ` Chris Pacia 2015-08-28 23:38 ` Mark Friedenbach 2015-08-28 23:46 ` Btc Drak 2015-08-28 23:38 ` Btc Drak 1 sibling, 2 replies; 26+ messages in thread From: Chris Pacia @ 2015-08-28 23:35 UTC (permalink / raw) To: Gavin; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2644 bytes --] 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 > [-- Attachment #2: Type: text/html, Size: 3683 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:35 ` Chris Pacia @ 2015-08-28 23:38 ` Mark Friedenbach 2015-08-28 23:42 ` Matt Whitlock ` (2 more replies) 2015-08-28 23:46 ` Btc Drak 1 sibling, 3 replies; 26+ messages in thread From: Mark Friedenbach @ 2015-08-28 23:38 UTC (permalink / raw) To: Chris Pacia; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3129 bytes --] 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 > > [-- Attachment #2: Type: text/html, Size: 4589 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:38 ` Mark Friedenbach @ 2015-08-28 23:42 ` Matt Whitlock 2015-08-28 23:42 ` Chris Pacia 2015-08-29 0:00 ` Jorge Timón 2 siblings, 0 replies; 26+ messages in thread From: Matt Whitlock @ 2015-08-28 23:42 UTC (permalink / raw) To: bitcoin-dev, Mark Friedenbach, Chris Pacia 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 > > > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:38 ` Mark Friedenbach 2015-08-28 23:42 ` Matt Whitlock @ 2015-08-28 23:42 ` Chris Pacia 2015-08-29 0:00 ` Jorge Timón 2 siblings, 0 replies; 26+ messages in thread From: Chris Pacia @ 2015-08-28 23:42 UTC (permalink / raw) To: Mark Friedenbach; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3561 bytes --] On Aug 28, 2015 7:38 PM, "Mark Friedenbach" <mark@friedenbach•org> wrote: > > It is in their individual interests when the larger block that is allowed for them grants them more fees. And pay a difficulty penalty and lose full blocks because of it? Even if fees are somehow high enough to compensate for the lost reward, it still requires miners to collectively decide to raise the block size for it to make sense individually. An individual vote will not raise the limit, but it will cost the miner money. > > 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 >> [-- Attachment #2: Type: text/html, Size: 5246 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:38 ` Mark Friedenbach 2015-08-28 23:42 ` Matt Whitlock 2015-08-28 23:42 ` Chris Pacia @ 2015-08-29 0:00 ` Jorge Timón 2015-08-29 0:29 ` Mark Friedenbach 2 siblings, 1 reply; 26+ messages in thread From: Jorge Timón @ 2015-08-29 0:00 UTC (permalink / raw) To: Mark Friedenbach, Jeff Garzik; +Cc: Bitcoin Dev On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > It is in their individual interests when the larger block that is allowed > for them grants them more fees. I realize now that this is not what Greg Maxwell proposed (aka flexcap): this is just miner's voting on block size but paying with higher difficulty when they vote for bigger blocks. As I said several times in other places, miners should not decide on the consensus rule to limit mining centralization. People keep talking about miners voting on the block size or "softforking the size down if we went too far". But what if the hashing majority is perfectly fine with the mining centralization at that point in time? Then a softfork won't be useful and we're talking about an "anti-miner fork" (see https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158 and https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175 ). I believe miner's voting on the rule to limit mining centralization is a terrible idea. It sounds as bad as letting pharma companies write the regulations on new drugs safety, letting big food chains deciding on minimum food controls or car manufacturers deciding on indirect taxes for fuel. That's why I dislike both this proposal and BIP100. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 0:00 ` Jorge Timón @ 2015-08-29 0:29 ` Mark Friedenbach 2015-08-29 10:15 ` Btc Drak 0 siblings, 1 reply; 26+ messages in thread From: Mark Friedenbach @ 2015-08-29 0:29 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2022 bytes --] Ah, then my mistake. It seemed so similar to an idea that was proposed before on this mailing list: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html that my mind just filled in the gaps. I concur -- having miners -- or any group -- vote on block size is not an intrinsically good thing. The the original proposal due to Greg Maxwell et al was not a mechanism for "voting" but rather a feedback control that made the maximum block size that which generated the most fees. On Fri, Aug 28, 2015 at 5:00 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > It is in their individual interests when the larger block that is allowed > > for them grants them more fees. > > I realize now that this is not what Greg Maxwell proposed (aka > flexcap): this is just miner's voting on block size but paying with > higher difficulty when they vote for bigger blocks. > As I said several times in other places, miners should not decide on > the consensus rule to limit mining centralization. > People keep talking about miners voting on the block size or > "softforking the size down if we went too far". But what if the > hashing majority is perfectly fine with the mining centralization at > that point in time? > Then a softfork won't be useful and we're talking about an "anti-miner > fork" (see > https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158 > and > https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175 > ). > > I believe miner's voting on the rule to limit mining centralization is > a terrible idea. > It sounds as bad as letting pharma companies write the regulations on > new drugs safety, letting big food chains deciding on minimum food > controls or car manufacturers deciding on indirect taxes for fuel. > That's why I dislike both this proposal and BIP100. > [-- Attachment #2: Type: text/html, Size: 2877 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 0:29 ` Mark Friedenbach @ 2015-08-29 10:15 ` Btc Drak 2015-08-29 17:51 ` Eric Lombrozo ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Btc Drak @ 2015-08-29 10:15 UTC (permalink / raw) To: Mark Friedenbach; +Cc: Bitcoin Dev On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Ah, then my mistake. It seemed so similar to an idea that was proposed > before on this mailing list: > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html > > that my mind just filled in the gaps. I concur -- having miners -- or any > group -- vote on block size is not an intrinsically good thing. The the > original proposal due to Greg Maxwell et al was not a mechanism for "voting" > but rather a feedback control that made the maximum block size that which > generated the most fees. Mark and Jorge, I am very glad you have brought up this particular objection because it's something I thought about but was unclear if it was an opinion that would be shared by others. I chose to omit it from the proposal to see if it would come up during peer review. I feel that giving miners a blank cheque to increase blocksize, by any means, goes against a key design of bitcoin's security model. Full nodes keep miners honest by ensuring by validating their blocks. Under any voting-only scheme there is no way for full nodes to keep miners in cheque because miner have free reign to increase the blocksize. This problem can be solved by introducing a hard cap on blocksize. By introducing an upper limit miners now have the freedom to increase blocksize but only within defined parameters. Remember my proposal allows blocksize to increase and decrease in such a way that miners must collectively agree if they want the size to increase. I believe the idea of a hard upper limit has become rather politicised but is essential to the security model of bitcoin. With respect to the flexicap idea where miners can create a larger block by paying extra difficulty, I believe that proposal has a critical flaw because, as Gavin pointed out, it makes it very expensive (and risky) to include a few extra transactions. I believe it suffers from tragedy of the commons because there is no incentive for the mining community to reach consensus. Each and every block is going to be a gamble, "should we include a few extra transactions at the risk of losing the block?". Under my proposal miners can collectively agree to change the blocksize. Let's say they want a 10% increase, they can collude together to make that increase and once reached, it remains until they want to change it again. Yet, the upper hard limit keeps the ultimate control of the maximum block size squarely in the hands of full nodes. Whilst the exact number may be up for discussion, I would propose an initial upper limit of 8MB, so under my proposal the blocksize would be flexible between 1MB and 8MB. An alternative methodology to voting in the coinbase would be to change the vote to be the blocksize itself 1. miners pay extra difficulty to create a larger block. 2. every 2016 blocks the average or median of the last 2016 blocks is calculated and becomes the new maximum blocksize limit. This would retain incentive to collude to increase blocksize, as well as the property of costing to increase while being free to propose decrease. It would still require an upper blocksize limit in order for full nodes to retain control. Without an upper limit, any proposal is going to break the security model as full nodes give up some oversight control over miners. Another way of looking at these ideas is we're raising blocksize hard limit (to 8MB or whatever is decided), but making a soft of "softer" or inner limit part of consensus. Such a concept is not really departing from the current idea of a soft limit except to make it consensus enforced. Obviously it's not identical, but I think you can see the similarities. Does that make sense? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 10:15 ` Btc Drak @ 2015-08-29 17:51 ` Eric Lombrozo 2015-08-29 19:13 ` Natanael 2015-08-29 19:03 ` jl2012 2015-08-29 20:41 ` Jorge Timón 2 siblings, 1 reply; 26+ messages in thread From: Eric Lombrozo @ 2015-08-29 17:51 UTC (permalink / raw) To: Btc Drak, Mark Friedenbach; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4745 bytes --] In principle I am sympathetic to dynamic block size proposals...but in practice it seems we're barking up the wrong tree. Without mechanisms for incentivizing validators...and checks and balances between the interests of regular users (who want to reduce fees and confirmation time), miners (who want to balance hashing and propagation time costs with revenue), and validator nodes (who currrently lack any direct incentives), I think we're talking about significant protocol complications with potential benefits that are hard to model at best. On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Ah, then my mistake. It seemed so similar to an idea that was proposed > > before on this mailing list: > > > > > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html > > > > that my mind just filled in the gaps. I concur -- having miners -- or any > > group -- vote on block size is not an intrinsically good thing. The the > > original proposal due to Greg Maxwell et al was not a mechanism for > "voting" > > but rather a feedback control that made the maximum block size that which > > generated the most fees. > > Mark and Jorge, > > I am very glad you have brought up this particular objection because > it's something I thought about but was unclear if it was an opinion > that would be shared by others. I chose to omit it from the proposal > to see if it would come up during peer review. > > I feel that giving miners a blank cheque to increase blocksize, by any > means, goes against a key design of bitcoin's security model. Full > nodes keep miners honest by ensuring by validating their blocks. Under > any voting-only scheme there is no way for full nodes to keep miners > in cheque because miner have free reign to increase the blocksize. > > This problem can be solved by introducing a hard cap on blocksize. By > introducing an upper limit miners now have the freedom to increase > blocksize but only within defined parameters. Remember my proposal > allows blocksize to increase and decrease in such a way that miners > must collectively agree if they want the size to increase. > > I believe the idea of a hard upper limit has become rather politicised > but is essential to the security model of bitcoin. > > With respect to the flexicap idea where miners can create a larger > block by paying extra difficulty, I believe that proposal has a > critical flaw because, as Gavin pointed out, it makes it very > expensive (and risky) to include a few extra transactions. I believe > it suffers from tragedy of the commons because there is no incentive > for the mining community to reach consensus. Each and every block is > going to be a gamble, "should we include a few extra transactions at > the risk of losing the block?". Under my proposal miners can > collectively agree to change the blocksize. Let's say they want a 10% > increase, they can collude together to make that increase and once > reached, it remains until they want to change it again. Yet, the upper > hard limit keeps the ultimate control of the maximum block size > squarely in the hands of full nodes. > > Whilst the exact number may be up for discussion, I would propose an > initial upper limit of 8MB, so under my proposal the blocksize would > be flexible between 1MB and 8MB. > > An alternative methodology to voting in the coinbase would be to > change the vote to be the blocksize itself > > 1. miners pay extra difficulty to create a larger block. > 2. every 2016 blocks the average or median of the last 2016 blocks is > calculated and becomes the new maximum blocksize limit. > > This would retain incentive to collude to increase blocksize, as well > as the property of costing to increase while being free to propose > decrease. > > It would still require an upper blocksize limit in order for full > nodes to retain control. Without an upper limit, any proposal is going > to break the security model as full nodes give up some oversight > control over miners. > > Another way of looking at these ideas is we're raising blocksize hard > limit (to 8MB or whatever is decided), but making a soft of "softer" > or inner limit part of consensus. Such a concept is not really > departing from the current idea of a soft limit except to make it > consensus enforced. Obviously it's not identical, but I think you can > see the similarities. > > Does that make sense? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5730 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 17:51 ` Eric Lombrozo @ 2015-08-29 19:13 ` Natanael 0 siblings, 0 replies; 26+ messages in thread From: Natanael @ 2015-08-29 19:13 UTC (permalink / raw) To: Eric Lombrozo; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2735 bytes --] My current idea: * There's a scheduled hardcap that goes up over time. * Miners vote on the blocksize limit within the hardcap, choosing the new votecap. No particular idea for scheduling change. The 2016 block period seems a bit long though, in case of sudden peak load. (I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes counted from block A to block B = block A+X, the change is enacted at block C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No suggestion on vote result calculation mechanism.) * Casting votes are free. * The mean (average) blocksize over the last time period X is calculated for every block, or at the end of every fixed-length period (depending on what scheduling is used for votes). * Creating blocks larger than the mean but below the votecap raises the difficulty target for the miner (and slightly raises the mean for future blocks). * The degree of difficulty raise depends on where between the mean and votecap that the size of the given block is (and it follows that lots of votes for large raise reduces per-extra-Kb penalty, allowing for cheaper peak load adjustment if a large miner majority agrees). The degree of increase may be either linear or logarithmic, I've got no suggestion currently on any particular metric. (Some might think this is an easy way for miners to collude to make large blocks cheaper. If so, you could commit to only pay fee to miners that don't vote for a block size above the size you accept, as a counter-incentive.) * Question: When the votecap is lowered, should the calculated mean be forced down to follow (forcing a penalty for making blocks close to the votecap straight after the change)? If so, how? Or should it be allowed to fall naturally as new blocks with size below the votecap are created? This is how miners would pay for actually creating larger blocks, and leaves us with three methods of keeping the size in check (hardcap, votecap and softcap). The softcap mechanism is then our third check to use if deemed necessary (orphaning valid blocks if considered problematically large). This third option do not need coordination with miners, they just need to be aware which block size is accepted by the community. I can't think of any sensible non-miner mechanism of deciding max block size outside of using a community coordinated softcap, anything else will not work reliably. Too hard to measure objectively and judge fairly. The community would thus agree on a hardcap schedule in advance, and have the option to threaten orphaning blocks via softfork later on if circumstances would change and the votecap is too large. [-- Attachment #2: Type: text/html, Size: 2962 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 10:15 ` Btc Drak 2015-08-29 17:51 ` Eric Lombrozo @ 2015-08-29 19:03 ` jl2012 2015-08-29 20:41 ` Jorge Timón 2 siblings, 0 replies; 26+ messages in thread From: jl2012 @ 2015-08-29 19:03 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev I am quite skeptical about any pay-to-increase proposal because it is difficult to predict the game dynamics and determine the right amount of penalty. But anyway, here is my response to your revised proposal: 1. I agree with you that there should be a cap in the rate of change, and also the maximum possible size. This is already part of BIP100 2. Requiring a higher difficulty is bad for everyone: a) it increases the variance of the miner; b) average confirmation time for all tx are increased. It may even cause a feedback: many tx in mempool -> increase block size -> wait longer for confirmation -> more tx in mempool; c) difficulty of the next round will be decreased, leading to a greater fluctuation in confirmation time. Instead, you should require miners to burn their coinbase reward. This is effectively same as higher difficulty but is good for everyone: a) mining variance and confirmation time unchanged; b) all bitcoin holders become relatively richer If you don't want to burn any bitcoin, you may require the miner the send to penalty to <840000 + current height> OP_CHECKLOCKTIMEVERIFY, which will subsidize the mining when the block reward drops below 1 BTC 3. It is a better idea to allow mining of a bigger block immediately, which reduces (but not eliminates) the problem of tragedy of the commons. However, you can't use the blocksize as the vote. Mining an empty block doesn't mean the miner wants to decrease the block size to 200 bytes. That will just encourage some miners to fill up a block with garbage which does no good for anyone. Therefore, you need to look at both the actual block size and the coinbase vote, and always take the bigger value to determine the penalty and the max block size of next round. If a miner includes nothing in the coinbase, it should be consider as a vote for the current max block size. Btc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到: > On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > Mark and Jorge, > > I am very glad you have brought up this particular objection because > it's something I thought about but was unclear if it was an opinion > that would be shared by others. I chose to omit it from the proposal > to see if it would come up during peer review. > > I feel that giving miners a blank cheque to increase blocksize, by any > means, goes against a key design of bitcoin's security model. Full > nodes keep miners honest by ensuring by validating their blocks. Under > any voting-only scheme there is no way for full nodes to keep miners > in cheque because miner have free reign to increase the blocksize. > > This problem can be solved by introducing a hard cap on blocksize. By > introducing an upper limit miners now have the freedom to increase > blocksize but only within defined parameters. Remember my proposal > allows blocksize to increase and decrease in such a way that miners > must collectively agree if they want the size to increase. > > I believe the idea of a hard upper limit has become rather politicised > but is essential to the security model of bitcoin. > > With respect to the flexicap idea where miners can create a larger > block by paying extra difficulty, I believe that proposal has a > critical flaw because, as Gavin pointed out, it makes it very > expensive (and risky) to include a few extra transactions. I believe > it suffers from tragedy of the commons because there is no incentive > for the mining community to reach consensus. Each and every block is > going to be a gamble, "should we include a few extra transactions at > the risk of losing the block?". Under my proposal miners can > collectively agree to change the blocksize. Let's say they want a 10% > increase, they can collude together to make that increase and once > reached, it remains until they want to change it again. Yet, the upper > hard limit keeps the ultimate control of the maximum block size > squarely in the hands of full nodes. > > Whilst the exact number may be up for discussion, I would propose an > initial upper limit of 8MB, so under my proposal the blocksize would > be flexible between 1MB and 8MB. > > An alternative methodology to voting in the coinbase would be to > change the vote to be the blocksize itself > > 1. miners pay extra difficulty to create a larger block. > 2. every 2016 blocks the average or median of the last 2016 blocks is > calculated and becomes the new maximum blocksize limit. > > This would retain incentive to collude to increase blocksize, as well > as the property of costing to increase while being free to propose > decrease. > > It would still require an upper blocksize limit in order for full > nodes to retain control. Without an upper limit, any proposal is going > to break the security model as full nodes give up some oversight > control over miners. > > Another way of looking at these ideas is we're raising blocksize hard > limit (to 8MB or whatever is decided), but making a soft of "softer" > or inner limit part of consensus. Such a concept is not really > departing from the current idea of a soft limit except to make it > consensus enforced. Obviously it's not identical, but I think you can > see the similarities. > > Does that make sense? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 10:15 ` Btc Drak 2015-08-29 17:51 ` Eric Lombrozo 2015-08-29 19:03 ` jl2012 @ 2015-08-29 20:41 ` Jorge Timón 2015-08-30 17:13 ` jl2012 2 siblings, 1 reply; 26+ messages in thread From: Jorge Timón @ 2015-08-29 20:41 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak <btcdrak@gmail•com> wrote: > On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >> Ah, then my mistake. It seemed so similar to an idea that was proposed >> before on this mailing list: >> >> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html >> >> that my mind just filled in the gaps. I concur -- having miners -- or any >> group -- vote on block size is not an intrinsically good thing. The the >> original proposal due to Greg Maxwell et al was not a mechanism for "voting" >> but rather a feedback control that made the maximum block size that which >> generated the most fees. > > Mark and Jorge, > > I am very glad you have brought up this particular objection because > it's something I thought about but was unclear if it was an opinion > that would be shared by others. I chose to omit it from the proposal > to see if it would come up during peer review. > > I feel that giving miners a blank cheque to increase blocksize, by any > means, goes against a key design of bitcoin's security model. Full > nodes keep miners honest by ensuring by validating their blocks. Under > any voting-only scheme there is no way for full nodes to keep miners > in cheque because miner have free reign to increase the blocksize. > > This problem can be solved by introducing a hard cap on blocksize. By > introducing an upper limit miners now have the freedom to increase > blocksize but only within defined parameters. Remember my proposal > allows blocksize to increase and decrease in such a way that miners > must collectively agree if they want the size to increase. Then I only care about the hard cap (for example, to me bip100 is practically equivalent to just raise the limit to 32 MB directly). Miners can always produce smaller blocks by modifying their local policy. So if we need a maximum that cannot be altered by miners anyway, why take the additional complexity of miners voting on a lower and changing maximum size? > With respect to the flexicap idea where miners can create a larger > block by paying extra difficulty, I believe that proposal has a > critical flaw because, as Gavin pointed out, it makes it very > expensive (and risky) to include a few extra transactions. I believe > it suffers from tragedy of the commons because there is no incentive > for the mining community to reach consensus. Each and every block is > going to be a gamble, "should we include a few extra transactions at > the risk of losing the block?". How expensive it is depends on the concrete function f(extra_nBits) = extra_size_allowed But the goal of that proposal is not to raise the size maximum permanently, but rather temporarily allow bigger blocks when there are spikes in demand (ie many fees to collect in unconfirmed transactions). Yes miners will ask that question to themselves, and the answer will depend on the concrete function and on the fees of those extra transactions. The miner paying for the costs will get the gains: no tragedy of the commons here. > Under my proposal miners can > collectively agree to change the blocksize. Let's say they want a 10% > increase, they can collude together to make that increase and once > reached, it remains until they want to change it again. Yet, the upper > hard limit keeps the ultimate control of the maximum block size > squarely in the hands of full nodes. I believe the tragedy of the commons actually happens with your proposal. Why would I pay alone for something that benefits all miners? > An alternative methodology to voting in the coinbase would be to > change the vote to be the blocksize itself > > 1. miners pay extra difficulty to create a larger block. > 2. every 2016 blocks the average or median of the last 2016 blocks is > calculated and becomes the new maximum blocksize limit. > > This would retain incentive to collude to increase blocksize, as well > as the property of costing to increase while being free to propose > decrease. This seems to solve the tragedy of the commons problem with your current proposal. It would be like flexcap but instead of the change in size being temporary, it affects the next maximum size permanently. One thing to worry about is miners filling blocks with pay-to-themselves garbage to avoid reducing the size when they don't have enough attractive transactions to include (ie it may not be free for the network for miners to vote on "maintain current size"). > It would still require an upper blocksize limit in order for full > nodes to retain control. Without an upper limit, any proposal is going > to break the security model as full nodes give up some oversight > control over miners. > > Another way of looking at these ideas is we're raising blocksize hard > limit (to 8MB or whatever is decided), but making a soft of "softer" > or inner limit part of consensus. Such a concept is not really > departing from the current idea of a soft limit except to make it > consensus enforced. Obviously it's not identical, but I think you can > see the similarities. > > Does that make sense? I still don't see the point in having a lower moving size maximum. If 8 MB is mining-centralization-safe, let's move directly to 8 MB without adding this seemingly useless extra complexity. If it's not, mining voting on a lower moving maximum won't make it safer. Once we have more objective tools (centralization metrics, simulators, etc...) to determine whether or not a block size is mining-centralization-safe for a given point in time (looking at current centralization and current technology available), I don't see the problem with repeating the equivalent of bip102 periodically (every 2 years?) to adapt the size to better technology or lower mining centralization. It would be also helpful to have a tool to somehow measure "size increase urgency" (ie right now free transactions get mined and blocks aren't full or close to be full, I don't think the current general sense of urgency on this matter is justified). With all respect, I believe bip100 and this proposal are over-engineering; and bip101 and bip103 (pieter's) are overly-optimistic (in their exponential technological growth assumptions). ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-29 20:41 ` Jorge Timón @ 2015-08-30 17:13 ` jl2012 2015-08-30 18:56 ` Jorge Timón 0 siblings, 1 reply; 26+ messages in thread From: jl2012 @ 2015-08-30 17:13 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到: > > I still don't see the point in having a lower moving size maximum. > If 8 MB is mining-centralization-safe, let's move directly to 8 MB > without adding this seemingly useless extra complexity. > If it's not, mining voting on a lower moving maximum won't make it > safer. > > Once we have more objective tools (centralization metrics, simulators, > etc...) to determine whether or not a block size is > mining-centralization-safe for a given point in time (looking at > current centralization and current technology available), I don't see > the problem with repeating the equivalent of bip102 periodically > (every 2 years?) to adapt the size to better technology or lower > mining centralization. > It would be also helpful to have a tool to somehow measure "size > increase urgency" (ie right now free transactions get mined and blocks > aren't full or close to be full, I don't think the current general > sense of urgency on this matter is justified). > > With all respect, I believe bip100 and this proposal are > over-engineering; and bip101 and bip103 (pieter's) are > overly-optimistic (in their exponential technological growth > assumptions). This is based on the assumption that miners would always like to use up the last byte of the available block size. However, this is just not true: 1. The 6 year blockchain history has shown that most miners have a soft cap with their block size. 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial 20MB proposal and asked for 8MB: http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size 3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with 8MB as a mid-term goal: https://vip.btcchina.com/page/noticetemplate?id=100. BTCChina is controlling 12% of the network in the past month. If BIP100 uses the 20-percentile vote as the block size, it takes only 8% more vote to keep the size at 2MB For many reasons miners may want to have a smaller block size, which we don't need to list them here. Although they can limit it by a softfork or even 51% attack, it is a very violent process. Why don't we just allow them to vote for a lower limit? So I think the right way is to choose a mining-centralization-safe limit, and let it free float within a range based on miner's vote. If we are lucky enough to have some responsible miners, they will keep it as low as possible, until the legitimate tx volume catches up. Even in the worst case, the block size is still mining-centralization-safe. The upper limit may increase linearly, if not exponentially, until we find a better long-term solution. (sort of a combination of BIP100 and 101, with different parameters) -------- For the matter of "urgency", I agree with you that there is no actual urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy (as you suggested), we really have the urgency to make a decision now. Actually, the main point is not urgency but uncertainty. We have debated for 5 years. Why won't we have 5 more years of debate, plus 5 years of deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin Core must be abandoned by the economic majority and a Schism fork must occur. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-30 17:13 ` jl2012 @ 2015-08-30 18:56 ` Jorge Timón 2015-08-31 18:50 ` jl2012 0 siblings, 1 reply; 26+ messages in thread From: Jorge Timón @ 2015-08-30 18:56 UTC (permalink / raw) To: jl2012; +Cc: Bitcoin Dev On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt•hk> wrote: > This is based on the assumption that miners would always like to use up the > last byte of the available block size. However, this is just not true: > > 1. The 6 year blockchain history has shown that most miners have a soft cap > with their block size. > > 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial > 20MB proposal and asked for 8MB: > http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size > [...] No, I'm not making such assumption. I'm focusing on what they CAN do, while suspending judgement on their good will and not trying to predict their future behavior from historic behaviour. With 60% of the hashrate, you can easily get 100% by orphaning everybody else's blocks. More importantly, being under the same jurisdiction they can be forced to behave in certain way (for example, censor transactions) by law. I'm very worried about the current situation no matter how benevolent current miners are. Thus weakening the only limit to mining centralization that we have at the consensus rule level seems extremely risky at this point. > For many reasons miners may want to have a smaller block size, which we > don't need to list them here. Although they can limit it by a softfork or > even 51% attack, it is a very violent process. Why don't we just allow them > to vote for a lower limit? > > So I think the right way is to choose a mining-centralization-safe limit, > and let it free float within a range based on miner's vote. If we are lucky > enough to have some responsible miners, they will keep it as low as > possible, until the legitimate tx volume catches up. Even in the worst case, > the block size is still mining-centralization-safe. The upper limit may > increase linearly, if not exponentially, until we find a better long-term > solution. (sort of a combination of BIP100 and 101, with different > parameters) My point is, a "soft cap" determined by miners clearly doesn't protect us from mining centralization: the "hard cap" does. Knowing that, and given that miners can currently set their own policy block size maximum, what does this "voting on a lower limit" achieve? What are the gains? Why are we "lucky" if they keep the lower one as low as possible? > For the matter of "urgency", I agree with you that there is no actual > urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy > (as you suggested), we really have the urgency to make a decision now. Thank you for admitting it is not urgent! I suggested 5 years for the concrete hardfork in bip99 because it's clearly non-urgent and I wanted to be very conservative. I'm happy to reduce that to say, 1 year (specially given that the change is very simple to implement). For a simple block size change (like, say bip102) 1 year (maybe 6 months + miner's confirmation) is probably more than enough as well. And we can always deploy an urgency hardfork if it is necessary. > Actually, the main point is not urgency but uncertainty. We have debated for > 5 years. Why won't we have 5 more years of debate, plus 5 years of > deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin > Core must be abandoned by the economic majority and a Schism fork must > occur. Fortunately we haven't been discussing this for 5 years, I don't know where you get that from. A schism fork it's certainly always a possibility but I would only consider it after an urgency hardfork (once the issue becomes urgent) fails due to not being uncontroversial. Would you agree with me on that? What would be your criterion for considering an increase in block size urgent? Mine is: we should consider a block increase only when minimum market fees for transactions to be mined (currently zero satoshis) increase above a high fee (admittedly undefined, but certainly greater than zero). Even if it's "urgent", I think we should only increase the maximum if, at the same time, the new size can be considered safe mining-centralization-wise (unfortunately we don't have any metric to measure that nor enough tools to realistically simulate different sizes in different network topologies at the moment). But once we have them, the next discussion will be much simpler, so I don't see the need for block size maximum that changes over time (neither exponentially nor linearly). Would you agree with me that mining centralization should be the most important criterion when changing the block size maximum rule rather than the level of minimum fees? If the community can't agree on this, I'm afraid there will be a schism hardfork eventually. Another possibility is that those who aren't concerned with mining centralization start their own altcoin (centralizedcoin? ), maybe a spinoff [ https://bitcointalk.org/index.php?topic=563972.0 ] if they want to keep Bitcoin's utxo at the moment of the separation. But if the community agrees with this and just disagrees on the maximum block size consensus rule having any effect on mining centralization (like Gavin and I disagree), we should calm down and use scientific processes to find out what the relation between the two actually is (if there's any relation at all). Would you agree with me on this? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-30 18:56 ` Jorge Timón @ 2015-08-31 18:50 ` jl2012 0 siblings, 0 replies; 26+ messages in thread From: jl2012 @ 2015-08-31 18:50 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev Jorge Timón 於 2015-08-30 14:56 寫到: > On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt•hk> wrote: >> This is based on the assumption that miners would always like to use >> up the >> last byte of the available block size. However, this is just not true: >> >> 1. The 6 year blockchain history has shown that most miners have a >> soft cap >> with their block size. >> >> 2. Chinese miners, controlling 60% of the network, rejected Gavin's >> initial >> 20MB proposal and asked for 8MB: >> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size >> [...] > > No, I'm not making such assumption. I'm focusing on what they CAN do, > while suspending judgement on their good will and not trying to > predict their future behavior from historic behaviour. > With 60% of the hashrate, you can easily get 100% by orphaning > everybody else's blocks. More importantly, being under the same > jurisdiction they can be forced to behave in certain way (for example, > censor transactions) by law. > I'm very worried about the current situation no matter how benevolent > current miners are. Thus weakening the only limit to mining > centralization that we have at the consensus rule level seems > extremely risky at this point. The reason for 60% of block were generated in China is same as the reason for 60% of your clothes were made in China. The electricity there is the cheapest on the planet. Many dams were built in the past 10 years and now they have huge amount of surplus electricity due to economic downturn. Not sure if you are aware of this thread: https://bitcointalk.org/index.php?topic=1072474.0 . Could you imagine this in any developed country? As long as mining is largely dependent on energy, there is no hope to break the balance/imbalance. Bandwidth is probably only a few percent of miners' cost. There is no evidence that the current level of centralization is a result of block size. Instead, clear evidence has shown that centralization is a result of pool mining*, invention of ASIC, and disparity of energy cost. (* People started pool mining in 2010 because they wanted lower variance, not because of the inability to run a full node) >> For many reasons miners may want to have a smaller block size, which >> we >> don't need to list them here. Although they can limit it by a softfork >> or >> even 51% attack, it is a very violent process. Why don't we just allow >> them >> to vote for a lower limit? >> >> So I think the right way is to choose a mining-centralization-safe >> limit, >> and let it free float within a range based on miner's vote. If we are >> lucky >> enough to have some responsible miners, they will keep it as low as >> possible, until the legitimate tx volume catches up. Even in the worst >> case, >> the block size is still mining-centralization-safe. The upper limit >> may >> increase linearly, if not exponentially, until we find a better >> long-term >> solution. (sort of a combination of BIP100 and 101, with different >> parameters) > > My point is, a "soft cap" determined by miners clearly doesn't protect > us from mining centralization: the "hard cap" does. > Knowing that, and given that miners can currently set their own policy > block size maximum, what does this "voting on a lower limit" achieve? > What are the gains? Why are we "lucky" if they keep the lower one as > low as possible? Even if we could quantify the level of centralization, it is a continuum and we must compromise between utility and centralization. Unless BIP101/103 is adopted, adjusting the hard cap always require a hardfork. For obvious technical and political reasons we can't have hardfork too frequently. Therefore, we need to leave some leeway: the hard cap may be a bit too high for today, but we are sure that technology will catch up in the near future. Assuming we have plenty amount of "benevolent" miners, they will keep the block size low unless there is a real demand for larger block space. This is different from setting an individual soft limit, as that will lead to block size scarcity and therefore higher tx fee, which may be good for all miners. And as we say "miners can always decrease the block size with softfork or 51% attack", BIP100 materializes this possibility in a much smoother way. I say "lucky" because I wholeheartedly believe it is good to keep the block as small as we really need. We can't do this by an equation so I would prefer to leave the power to miners (and they always have this power, anyway). > >> For the matter of "urgency", I agree with you that there is no actual >> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to >> deploy >> (as you suggested), we really have the urgency to make a decision now. > > Thank you for admitting it is not urgent! > I suggested 5 years for the concrete hardfork in bip99 because it's > clearly non-urgent and I wanted to be very conservative. I'm happy to > reduce that to say, 1 year (specially given that the change is very > simple to implement). > For a simple block size change (like, say bip102) 1 year (maybe 6 > months + miner's confirmation) is probably more than enough as well. > And we can always deploy an urgency hardfork if it is necessary. > >> Actually, the main point is not urgency but uncertainty. We have >> debated for >> 5 years. Why won't we have 5 more years of debate, plus 5 years of >> deployment delay? Are we sticking to 1MB for 10 years? In that case >> Bitcoin >> Core must be abandoned by the economic majority and a Schism fork must >> occur. > > Fortunately we haven't been discussing this for 5 years, I don't know > where you get that from. Jeff and Satoshi discussed this in 2010, although the flame throwing debate did not start until 2013. > A schism fork it's certainly always a possibility but I would only > consider it after an urgency hardfork (once the issue becomes urgent) > fails due to not being uncontroversial. > Would you agree with me on that? > What would be your criterion for considering an increase in block size > urgent? The problem is the definition of "urgency" itself is controversial. And I believe an urgent hardfork should only be done as a bug fix, not implementation of a new feature. Block size increase should be a planned feature, as we don't want the tx fee raised to 10USD, before suddenly dropping to 0.01USD with the hardfork. I don't think it's urgent today because my free tx always get mined. I don't know what is urgent and different people have different definition, but in general I think that should be measured by tx fee in USD. 0.001USD/byte may be intolerable for many people. (It's about $0.0001/byte now, and $0.0005/byte when it was $1200/BTC). It's not difficult to reach this level given the halving and potential bull market is coming. > Mine is: we should consider a block increase only when minimum market > fees for transactions to be mined (currently zero satoshis) increase > above a high fee (admittedly undefined, but certainly greater than > zero). As I argued above, it's already too late when things become really urgent. That will lead to serious market disruption, and the uncertainty could be very harmful to the development of the bitcoin economy. > Even if it's "urgent", I think we should only increase the maximum if, > at the same time, the new size can be considered safe > mining-centralization-wise (unfortunately we don't have any metric to > measure that nor enough tools to realistically simulate different > sizes in different network topologies at the moment). But once we have > them, the next discussion will be much simpler, so I don't see the > need for block size maximum that changes over time (neither > exponentially nor linearly). > > Would you agree with me that mining centralization should be the most > important criterion when changing the block size maximum rule rather > than the level of minimum fees? As I said above, strictly limiting the block size may have little effect on mining centralization (because block size at this level is not a determining factor), while it may seriously suppress the utility. I'm all for mining decentralization but block size is just not the right way to improve the situation. > If the community can't agree on this, I'm afraid there will be a > schism hardfork eventually. Another possibility is that those who > aren't concerned with mining centralization start their own altcoin > (centralizedcoin? ), maybe a spinoff [ > https://bitcointalk.org/index.php?topic=563972.0 ] if they want to > keep Bitcoin's utxo at the moment of the separation. > > But if the community agrees with this and just disagrees on the > maximum block size consensus rule having any effect on mining > centralization (like Gavin and I disagree), we should calm down and > use scientific processes to find out what the relation between the two > actually is (if there's any relation at all). > > Would you agree with me on this? I agree with you, but the balance between centralization and utility is also important. (and I believe the difference between 1MB and 8MB is tolerable, at least I must keep my full node running at this level) I also have an idea to have a "decentralizedcoin", with very small blocks and everyone could mine with a CPU. That would be interesting if it is backed by famous devs in this area and is not yet-another-scamcoin. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:35 ` Chris Pacia 2015-08-28 23:38 ` Mark Friedenbach @ 2015-08-28 23:46 ` Btc Drak 2015-08-29 9:15 ` Elliot Olds 1 sibling, 1 reply; 26+ messages in thread From: Btc Drak @ 2015-08-28 23:46 UTC (permalink / raw) To: Chris Pacia; +Cc: Bitcoin Dev On Sat, Aug 29, 2015 at 12:35 AM, 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. It is clear from recent events that miners are willing to collaborate together for the greater good of their industry. Miners have also publicly shown support for raising the blocksize collaboratively. Obviously, as transaction volume grows they want to collect as many transaction fees as possible so if there isnt enough space in blocks, they're going to vote for increases because it's in their collective financial interests. The proposal specifically encourages collaboration and hinders antisocial behaviour, and it specifically encourages the blocksize to be raised according to demand without neutering the fee market. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:46 ` Btc Drak @ 2015-08-29 9:15 ` Elliot Olds 0 siblings, 0 replies; 26+ messages in thread From: Elliot Olds @ 2015-08-29 9:15 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1517 bytes --] On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev > > It may be in everyone's collective interest to raise the block size but > not > > their individual interest. > > It is clear from recent events that miners are willing to collaborate > together for the greater good of their industry. Miners have also > publicly shown support for raising the blocksize collaboratively. > When have miners shown a willingness to make sacrifices for miners as a whole when they've been in a "public good"[1] situation? Miners collaborating to release statements to the public about which BIPs they support is very different from miners incurring costs only to themselves in order to help the entire group. They might do so, but it isn't clear. I agree with Jorge and Mark that allowing miners to vote on the block size is not ideal. Miners interests are somewhat aligned with those of the broader community, but not perfectly aligned. The block size level that maximizes miner revenue is not necessarily desirable overall. More miner revenue is only good if the marginal extra security that it buys is worth the extra cost. In addition to the cost of higher user fees, there's another hidden cost. In Bitcoin's early stages trying to maximize revenue too soon can slow growth and result in less revenue when it's more needed (when block rewards are much lower). [1] https://en.wikipedia.org/wiki/Public_good [-- Attachment #2: Type: text/html, Size: 2092 bytes --] ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 22:24 ` Gavin 2015-08-28 23:35 ` Chris Pacia @ 2015-08-28 23:38 ` Btc Drak 1 sibling, 0 replies; 26+ messages in thread From: Btc Drak @ 2015-08-28 23:38 UTC (permalink / raw) To: Gavin; +Cc: bitcoin-dev On Fri, Aug 28, 2015 at 11:24 PM, Gavin <gavinandresen@gmail•com> 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 Typo, 0.01111 > ... Or $2.50 at today's exchange rate. > > That seems excessive. I am not sure how it is relevant to this proposal because miners are not paying to include an extra transaction. The BIP details how miners can vote for a larger block size limit during a window of 2016 blocks. The block size limit does not increase during this phase. The block size limit is adjusted at the end of the sample window and the new size is valid until the next retargetting. If this wasn't clear, please let me know if I need to clarify any specifics in the wording of the proposal. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 21:15 ` Matt Whitlock 2015-08-28 22:24 ` Gavin @ 2015-08-28 23:36 ` Btc Drak 2015-08-28 23:44 ` Jorge Timón 1 sibling, 1 reply; 26+ messages in thread From: Btc Drak @ 2015-08-28 23:36 UTC (permalink / raw) To: Matt Whitlock; +Cc: Bitcoin Dev On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip@mattwhitlock•name> wrote: > 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? I chose not to address hard fork methodology at this stage because I wanted to focus on the main algorithm. There are a number of options open to us for deployment including a simple fixed activation (which I think is feasible because there is a a lot of awareness and the industry shows they are willing to rally around a single proposal). If there are any strong preferences, I can add a deployment section although I think it's less interesting until we forge a clear way forward with what blocksize proposal to use. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 23:36 ` Btc Drak @ 2015-08-28 23:44 ` Jorge Timón 0 siblings, 0 replies; 26+ messages in thread From: Jorge Timón @ 2015-08-28 23:44 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev On Sat, Aug 29, 2015 at 1:36 AM, Btc Drak via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip@mattwhitlock•name> wrote: >> 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? > > I chose not to address hard fork methodology at this stage because I > wanted to focus on the main algorithm. There are a number of options > open to us for deployment including a simple fixed activation (which I > think is feasible because there is a a lot of awareness and the > industry shows they are willing to rally around a single proposal). If > there are any strong preferences, I can add a deployment section > although I think it's less interesting until we forge a clear way > forward with what blocksize proposal to use. Can we please not discuss an ideal deployment mechanism in 4+ different proposals and discuss the same deployment mechanism (for all proposals) in BIP99's thread instead? ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft) 2015-08-28 20:28 ` Btc Drak 2015-08-28 21:15 ` Matt Whitlock @ 2015-08-29 9:38 ` jl2012 1 sibling, 0 replies; 26+ messages in thread From: jl2012 @ 2015-08-29 9:38 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev We need some game theory experts to analyse this but I see there are 3 major problems: 1. Tragedy of the commons: Some miners have to scarify their income to increase the block size, and all miners will share the beneficial outcome of the increase. All miners would like to be free riders. 2. Promote the formation of mining cartel: miners have to make sure that their vote for increase is supported by at least 50% of miners, or they will lose income for nothing. A miner also needs to make sure that he is not voting "excessively" (in terms of size and vote count), as the excessive part will never be counted due to the use of median. So basically you will either have exactly 1009 miners voting for the same size increase in a cycle, or have no vote for increase at all. That will require a lot of offline negotiations. Such cartel may work ONLY if mining is highly centralized, and miners trust each other. Also, there is no mechanism to punish those who betray the cartel. 3. Imbalance of power: it is costly to increase the size, while totally free to decrease the size Btc Drak via bitcoin-dev 於 2015-08-28 16:28 寫到: > I have received a lot of feedback on the original gist[1], reddit[2], > ML and IRC and have reworked the text somewhat. > > I also request the BIP maintainer for a BIP number assignment > > [1] https://gist.github.com/btcdrak/1c3a323100a912b605b5 > [2] > https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/ > > Pull request: https://github.com/bitcoin/bips/pull/187 > > <pre> > BIP: XX > Title: Consensus based block size retargeting algorithm > Author: BtcDrak <btcdrak@gmail•com> > Status: Draft > Type: Standards Track > Created: 2015-08-21 > </pre> > > ==Abstract== > > A method of altering the maximum allowed block size of the Bitcoin > protocol > using a consensus based approach. > > ==Motivation== > > There is a belief that Bitcoin cannot easily respond to raising the > blocksize limit if popularity was to suddenly increase due to a mass > adoption > curve, because co-ordinating a hard fork takes considerable time, and > being > unable to respond in a timely manner would irreparably harm the > credibility of > bitcoin. > > Additionally, predetermined block size increases are problematic > because they > attempt to predict the future, and if too large could have unintended > consequences like damaging the possibility for a fee market to develop > as block subsidy decreases substantially over the next 9 years; > introducing > or exacerbating mining attack vectors; or somehow affect the network in > unknown > or unpredicted ways. Since fixed changes are hard to deploy, the damage > could be > extensive. > > Dynamic block size adjustments also suffer from the potential to be > gamed by the > larger hash power. > > Free voting as suggested by BIP100 allows miners to sell their votes > out of band > at no risk, and enable the sponsor the ability to manipulate the > blocksize. > It also provides a cost free method or the larger pools to vote in ways > to > manipulate the blocksize such to disadvantage or attack smaller pools. > > > ==Rationale== > > By introducing a cost to increase the block size ensures the mining > community > will collude to increase it only when there is a clear necessity, and > reduce it > when it is unnecessary. Larger miners cannot force their wishes so > easily > because not only will they have to pay extra a difficulty target, then > can be > downvoted at no cost by the objecting hash power. > > Using difficulty as a penalty is better than a fixed cost in bitcoins > because it > is less predictable. > > > ==Specification== > > The initial block size limit shall be 1MB. > > Each time a miner creates a block, they may vote to increase or > decrease the > blocksize by a maximum of 10% of the current block size limit. These > votes will > be used to recalculate the new block size limit every 2016 blocks. > > Votes are cast using the block's coinbase field. > > The first 4 bytes of the coinbase field shall be repurposed for voting > as an > unsigned long integer which will be the block size in bytes. > > If a miner votes for an increase, the block hash must meet a difficulty > target > which is proportionally larger than the standard difficulty target > based on the > percentage increase they voted for. > > Votes proposing decreasing the block size limit do not need to meet a > higher > difficulty target. > > Miners can vote for no change by voting for the current block size. > > For blocks to be valid the blockhash must meet the required difficulty > target > for the vote otherwise the block is invalid and will be rejected. > > Every 2016 blocks, the block size limit will be recalculated by the > median of > all votes in the last 2016 blocks. This will redefine the block size > limit for > the next 2016 blocks. > > Blocks that are larger than the calculated base block size limit are > invalid and > will be rejected. > > The base block size limit may not reduce below 1MB. > > > ==Acknowledgements== > > This proposal is based on ideas and concepts derived from the writings > of > Meni Rosenfeld and Gregory Maxwell. > > > ==Copyright== > > This work is placed in the public domain. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-08-31 18:50 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak 2015-08-21 23:17 ` Paul Sztorc 2015-08-22 0:06 ` Ahmed Zsales 2015-08-28 20:28 ` Btc Drak 2015-08-28 21:15 ` Matt Whitlock 2015-08-28 22:24 ` Gavin 2015-08-28 23:35 ` Chris Pacia 2015-08-28 23:38 ` Mark Friedenbach 2015-08-28 23:42 ` Matt Whitlock 2015-08-28 23:42 ` Chris Pacia 2015-08-29 0:00 ` Jorge Timón 2015-08-29 0:29 ` Mark Friedenbach 2015-08-29 10:15 ` Btc Drak 2015-08-29 17:51 ` Eric Lombrozo 2015-08-29 19:13 ` Natanael 2015-08-29 19:03 ` jl2012 2015-08-29 20:41 ` Jorge Timón 2015-08-30 17:13 ` jl2012 2015-08-30 18:56 ` Jorge Timón 2015-08-31 18:50 ` jl2012 2015-08-28 23:46 ` Btc Drak 2015-08-29 9:15 ` Elliot Olds 2015-08-28 23:38 ` Btc Drak 2015-08-28 23:36 ` Btc Drak 2015-08-28 23:44 ` Jorge Timón 2015-08-29 9:38 ` jl2012
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox