📅 Original date posted:2015-08-21
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c9e0bb54/attachment.html>;
Ahmed Zsales [ARCHIVE] /
npub105…lgz5a
2023-06-07 15:49:14
in reply to nevent1q…qrgp
Author Public Key
npub105eg2ny7gs448umtlsn4ns4slc5q3se8wpnzhtr22j8sgdrv2q7stlgz5aPublished at
2023-06-07 15:49:14Event JSON
{
"id": "422d7c1d9d120e9e92e8384a3649b2b09776638332c5fe6b2a8a49586731f2b6",
"pubkey": "7d32854c9e442b53f36bfc2759c2b0fe2808c32770662bac6a548f04346c503d",
"created_at": 1686152954,
"kind": 1,
"tags": [
[
"e",
"56b0adbf3d1d3d1065cfb99fb9d090666fd73ffb1d30c585af39837300065d3f",
"",
"root"
],
[
"e",
"eeba81bc2309bd54a7fd7adbc5f4684f15fb79463638ca82be8093c631f3626e",
"",
"reply"
],
[
"p",
"7ac0bd39b854f24cbf067103758f3a9d398c23832d6d75824d190ae35c6c23be"
]
],
"content": "📅 Original date posted:2015-08-21\n📝 Original message:Interesting.\n\nUnless I misunderstand the proposal, you would have to factor a way to deal\nwith miner cartel behavior. A few emails every week and the larger miners\ncould collude to set prices.\n\nWith that figured, then your voting proposal could be triggered by a moving\nday block average which takes into account capacity for any given period,\nplus a level of headroom for unexpected spikes. The issue with this is\nforward planning is more important, especially when the moving average is\nlonger than a week.\n\nCredit card providers and retailers use a number of factors to plan for\ncapacity on a regional basis. From previous years figures, long-term\nweather forecasts, annual calendar events, one off events, etc. A global\ncurrency can't use many of these tools for forward planning.\n\nE.g. religious holidays are among the biggest events for transactions; if\nwe take Christmas, your proposal could work out a capacity during a quiet\nperiod in November leading to a downward adjustment which then sees\ntransactions getting maxed out during the two weeks before Christmas eve.\nYou could then have an upward adjustment, but people stop spending on\nChristmas day.\n\nThese are human factors that need to be considered.\n\nOn Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I wanted to offer a potential way to adjust the block size limit in a\n\u003e democratic way without making it easy to game. This is meant only as a\n\u003e starting point for a general idea. Thresholds and exact figures and\n\u003e the details of the algorithm are up for debate, and possibly some\n\u003e formula based determination.\n\u003e\n\u003e The living document is currently a gist available at\n\u003e https://gist.github.com/btcdrak/1c3a323100a912b605b5\n\u003e\n\u003e\n\u003e \u003cpre\u003e\n\u003e BIP: XX\n\u003e Title: Consensus based block size retargeting algorithm\n\u003e Author: BtcDrak \u003cbtcdrak at gmail.com\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2015-08-21\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e A method of altering the maximum allowed block size of the Bitcoin\n\u003e protocol using a consensus based approach.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e There is a perception that Bitcoin cannot easily respond to raising\n\u003e the blocksize limit if popularity was to suddenly increase due to a\n\u003e mass adoption curve, because co-ordinating a hard fork takes\n\u003e considerable time, and being unable to respond in a timely manner\n\u003e would irreparably harm the credibility of bitcoin.\n\u003e\n\u003e Additionally, predetermined block size increases are problematic\n\u003e because they attempt to predict the future, and if too large could\n\u003e have unintended consequences like damaging the possibility for a fee\n\u003e market to develop as block subsidy decreases substantially over the\n\u003e next 9 years; introducing or exacerbating mining attack vectors; or\n\u003e somehow affect the network in unknown or unpredicted ways. Since fixed\n\u003e changes are hard to deploy, the damage could be extensive.\n\u003e\n\u003e Dynamic block size adjustments also suffer from the potential to be\n\u003e gamed by the larger hash power.\n\u003e\n\u003e\n\u003e ==Rationale==\n\u003e\n\u003e By introducing a cost to increase the block size ensures the mining\n\u003e community will collude to increase it only when there is a clear\n\u003e necessity, and reduce it when it is unnecessary. Rogue miners cannot\n\u003e force their wishes so easily because not only will they have to pay\n\u003e extra a difficulty target, then can be downvoted at no cost by the\n\u003e objecting hash power.\n\u003e\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e The initial \"base block size limit\" shall be 1MB.\n\u003e\n\u003e Miners can vote for a block size increase by signalling the proposed\n\u003e percentage increase of the \"base block size limit\" in the coinbase\n\u003e field. For the vote to be considered valid the block they mine must\n\u003e meets a difficulty target which is proportionally larger than the\n\u003e standard difficulty target based on the percentage increase they voted\n\u003e for. If a miner does not vote, or the vote is invalid, it shall be\n\u003e counted as a vote for no change.\n\u003e\n\u003e Miners may vote the size down by signalling in the coinbase field\n\u003e without paying a difficulty penalty.\n\u003e\n\u003e Every 2016 blocks, the maximum allowed block size will be recalculated\n\u003e by the average of all votes in the last 2016 blocks, i.e. sum each\n\u003e vote from each block and divide by 2016 then multiply by the base\n\u003e block size limit. This will redefine the base block size limit for the\n\u003e next 2016 blocks.\n\u003e\n\u003e Blocks that are larger than the calculated base block size limit are\n\u003e invalid and MUST be rejected.\n\u003e\n\u003e The maximum change up or down each retargeting period shall be limited\n\u003e to 10% of the base block size limit.\n\u003e\n\u003e The maximum block size may not increase above 8MB.\n\u003e\n\u003e Votes shall be cast by adding the following human readable multiplier\n\u003e to the coinbase string “/BXn.nnn/” where valid votes would exist\n\u003e between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%\n\u003e increase). “/BX1.000/” would be a vote for no change. Invalid votes\n\u003e will be counted as a vote for no change: “/BX1.000/”.\n\u003e\n\u003e\n\u003e ==Acknowledgements==\n\u003e\n\u003e This proposal is based on ideas and concepts derived from the writings\n\u003e of Meni Rosenfeld and Gregory Maxwell.\n\u003e\n\u003e\n\u003e ==Copyright==\n\u003e\n\u003e This work is placed in the public domain.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150822/c9e0bb54/attachment.html\u003e",
"sig": "3d5e1a7a395a9089c0ccfc043b888fdae886275da0d882967dfaf05a1a0e6dde98f27310513e5b6ff5dfb0b0c411f62c7d87df170f0daf4f2a5f9f9630525ef6"
}