{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:It is my professional opinion that raising the block size by merely\nadjusting a constant without any sort of feedback mechanism would be a\ndangerous and foolhardy thing to do. We are custodians of a multi-billion\ndollar asset, and it falls upon us to weigh the consequences of our own\nactions against the combined value of the entire bitcoin ecosystem. Ideally\nwe would take no action for which we are not absolutely certain of the\nramifications, with the information that can be made available to us. But\nof course that is not always possible: there are unknown-unknowns, time\npressures, and known-unknowns where information has too high a marginal\ncost. So where certainty is unobtainable, we must instead hedge against\nunwanted outcomes.\n\nThe proposal to raise the block size now by redefining a constant carries\nwith it risk associated with infrastructure scaling, centralization\npressures, and delaying the necessary development of a constraint-based fee\neconomy. It also simply kicks the can down the road in settling these\nissues because a larger but realistic hard limit must still exist, meaning\na future hard fork may still be required.\n\nBut whatever new hard limit is chosen, there is also a real possibility\nthat it may be too high. The standard response is that it is a soft-fork\nchange to impose a lower block size limit, which miners could do with a\nminimal amount of coordination. This is however undermined by the\nunfortunate reality that so many mining operations are absentee-run\nbusinesses, or run by individuals without a strong background in bitcoin\nprotocol policy, or with interests which are not well aligned with other\nusers or holders of bitcoin. We cannot rely on miners being vigilant about\nissues that develop, as they develop, or able to respond in the appropriate\nfashion that someone with full domain knowledge and an objective\nperspective would.\n\nThe alternative then is to have some sort of dynamic block size limit\ncontroller, and ideally one which applies a cost to raising the block size\nin some way the preserves the decentralization and/or long-term stability\nfeatures that we care about. I will now describe one such proposal:\n\n  * For each block, the miner is allowed to select a different difficulty\n(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,\nand this miner-selected difficulty is used for the proof of work check. In\naddition to adjusting the hashcash target, selecting a different difficulty\nalso raises or lowers the maximum block size for that block by a function\nof the difference in difficulty. So increasing the difficulty of the block\nby an additional 25% raises the block limit for that block from 100% of the\ncurrent limit to 125%, and lowering the difficulty by 10% would also lower\nthe maximum block size for that block from 100% to 90% of the current\nlimit. For simplicity I will assume a linear identity transform as the\nfunction, but a quadratic or other function with compounding marginal cost\nmay be preferred.\n\n  * The default maximum block size limit is then adjusted at regular\nintervals. For simplicity I will assume an adjustment at the end of each\n2016 block interval, at the same time that difficulty is adjusted, but\nthere is no reason these have to be aligned. The adjustment algorithm\nitself is either the selection of the median, or perhaps some sort of\nweighted average that respects the \"middle majority.\" There would of course\nbe limits on how quickly the block size limit can adjusted in any one\nperiod, just as there are min/max limits on the difficulty adjustment.\n\n  * To prevent perverse mining incentives, the original difficulty without\nadjustment is used in the aggregate work calculations for selecting the\nmost-work chain, and the allowable miner-selected adjustment to difficulty\nwould have to be tightly constrained.\n\nThese rules create an incentive environment where raising the block size\nhas a real cost associated with it: a more difficult hashcash target for\nthe same subsidy reward. For rational miners that cost must be\ncounter-balanced by additional fees provided in the larger block. This\nallows block size to increase, but only within the confines of a\nself-supporting fee economy.\n\nWhen the subsidy goes away or is reduced to an insignificant fraction of\nthe block reward, this incentive structure goes away. Hopefully at that\ntime we would have sufficient information to soft-fork set a hard block\nsize maximum. But in the mean time, the block size limit controller\nconstrains the maximum allowed block size to be within a range supported by\nfees on the network, providing an emergency relief valve that we can be\nassured will only be used at significant cost.\n\nMark Friedenbach\n\n* There has over time been various discussions on the bitcointalk forums\nabout dynamically adjusting block size limits. The true origin of the idea\nis unclear at this time (citations would be appreciated!) but a form of it\nwas implemented in Bytecoin / Monero using subsidy burning to increase the\nblock size. That approach has various limitations. These were corrected in\nGreg Maxwell's suggestion to adjust the difficulty/nBits field directly,\nwhich also has the added benefit of providing incentive for bidirectional\nmovement during the subsidy period. The description in this email and any\nerrors are my own.\n\nOn Fri, May 8, 2015 at 12:20 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e\nwrote:\n\n\u003e Between all the flames on this list, several ideas were raised that did\n\u003e not get much attention. I hereby resubmit these ideas for consideration and\n\u003e discussion.\n\u003e\n\u003e - Perhaps the hard block size limit should be a function of the actual\n\u003e block sizes over some trailing sampling period. For example, take the\n\u003e median block size among the most recent 2016 blocks and multiply it by 1.5.\n\u003e This allows Bitcoin to scale up gradually and organically, rather than\n\u003e having human beings guessing at what is an appropriate limit.\n\u003e\n\u003e - Perhaps the hard block size limit should be determined by a vote of the\n\u003e miners. Each miner could embed a desired block size limit in the coinbase\n\u003e transactions of the blocks it publishes. The effective hard block size\n\u003e limit would be that size having the greatest number of votes within a\n\u003e sliding window of most recent blocks.\n\u003e\n\u003e - Perhaps the hard block size limit should be a function of block-chain\n\u003e length, so that it can scale up smoothly rather than jumping immediately to\n\u003e 20 MB. This function could be linear (anticipating a breakdown of Moore's\n\u003e Law) or quadratic.\n\u003e\n\u003e I would be in support of any of the above, but I do not support Mike\n\u003e Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the\n\u003e road without actually solving the problem, and it does so in a\n\u003e controversial (step function) way.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/ba1d33d5/attachment.html\u003e"}