{"type":"rich","version":"1.0","author_name":"npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","author_url":"https://nostr.ae/npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:This is a clever way to tie block size to fees.\n\nI would just like to point out though that it still fundamentally is using\nhard block size limits to enforce scarcity. Transactions with below market\nfees will hang in limbo for days and fail, instead of failing immediately\nby not propagating, or seeing degraded, long confirmation times followed by\neventual success.\n\n\nAaron Voisine\nco-founder and CEO\nbreadwallet.com\n\nOn Fri, May 8, 2015 at 1:33 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e It is my professional opinion that raising the block size by merely\n\u003e adjusting a constant without any sort of feedback mechanism would be a\n\u003e dangerous and foolhardy thing to do. We are custodians of a multi-billion\n\u003e dollar asset, and it falls upon us to weigh the consequences of our own\n\u003e actions against the combined value of the entire bitcoin ecosystem. Ideally\n\u003e we would take no action for which we are not absolutely certain of the\n\u003e ramifications, with the information that can be made available to us. But\n\u003e of course that is not always possible: there are unknown-unknowns, time\n\u003e pressures, and known-unknowns where information has too high a marginal\n\u003e cost. So where certainty is unobtainable, we must instead hedge against\n\u003e unwanted outcomes.\n\u003e\n\u003e The proposal to raise the block size now by redefining a constant carries\n\u003e with it risk associated with infrastructure scaling, centralization\n\u003e pressures, and delaying the necessary development of a constraint-based fee\n\u003e economy. It also simply kicks the can down the road in settling these\n\u003e issues because a larger but realistic hard limit must still exist, meaning\n\u003e a future hard fork may still be required.\n\u003e\n\u003e But whatever new hard limit is chosen, there is also a real possibility\n\u003e that it may be too high. The standard response is that it is a soft-fork\n\u003e change to impose a lower block size limit, which miners could do with a\n\u003e minimal amount of coordination. This is however undermined by the\n\u003e unfortunate reality that so many mining operations are absentee-run\n\u003e businesses, or run by individuals without a strong background in bitcoin\n\u003e protocol policy, or with interests which are not well aligned with other\n\u003e users or holders of bitcoin. We cannot rely on miners being vigilant about\n\u003e issues that develop, as they develop, or able to respond in the appropriate\n\u003e fashion that someone with full domain knowledge and an objective\n\u003e perspective would.\n\u003e\n\u003e The alternative then is to have some sort of dynamic block size limit\n\u003e controller, and ideally one which applies a cost to raising the block size\n\u003e in some way the preserves the decentralization and/or long-term stability\n\u003e features that we care about. I will now describe one such proposal:\n\u003e\n\u003e   * For each block, the miner is allowed to select a different difficulty\n\u003e (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,\n\u003e and this miner-selected difficulty is used for the proof of work check. In\n\u003e addition to adjusting the hashcash target, selecting a different difficulty\n\u003e also raises or lowers the maximum block size for that block by a function\n\u003e of the difference in difficulty. So increasing the difficulty of the block\n\u003e by an additional 25% raises the block limit for that block from 100% of the\n\u003e current limit to 125%, and lowering the difficulty by 10% would also lower\n\u003e the maximum block size for that block from 100% to 90% of the current\n\u003e limit. For simplicity I will assume a linear identity transform as the\n\u003e function, but a quadratic or other function with compounding marginal cost\n\u003e may be preferred.\n\u003e\n\u003e   * The default maximum block size limit is then adjusted at regular\n\u003e intervals. For simplicity I will assume an adjustment at the end of each\n\u003e 2016 block interval, at the same time that difficulty is adjusted, but\n\u003e there is no reason these have to be aligned. The adjustment algorithm\n\u003e itself is either the selection of the median, or perhaps some sort of\n\u003e weighted average that respects the \"middle majority.\" There would of course\n\u003e be limits on how quickly the block size limit can adjusted in any one\n\u003e period, just as there are min/max limits on the difficulty adjustment.\n\u003e\n\u003e   * To prevent perverse mining incentives, the original difficulty without\n\u003e adjustment is used in the aggregate work calculations for selecting the\n\u003e most-work chain, and the allowable miner-selected adjustment to difficulty\n\u003e would have to be tightly constrained.\n\u003e\n\u003e These rules create an incentive environment where raising the block size\n\u003e has a real cost associated with it: a more difficult hashcash target for\n\u003e the same subsidy reward. For rational miners that cost must be\n\u003e counter-balanced by additional fees provided in the larger block. This\n\u003e allows block size to increase, but only within the confines of a\n\u003e self-supporting fee economy.\n\u003e\n\u003e When the subsidy goes away or is reduced to an insignificant fraction of\n\u003e the block reward, this incentive structure goes away. Hopefully at that\n\u003e time we would have sufficient information to soft-fork set a hard block\n\u003e size maximum. But in the mean time, the block size limit controller\n\u003e constrains the maximum allowed block size to be within a range supported by\n\u003e fees on the network, providing an emergency relief valve that we can be\n\u003e assured will only be used at significant cost.\n\u003e\n\u003e Mark Friedenbach\n\u003e\n\u003e * There has over time been various discussions on the bitcointalk forums\n\u003e about dynamically adjusting block size limits. The true origin of the idea\n\u003e is unclear at this time (citations would be appreciated!) but a form of it\n\u003e was implemented in Bytecoin / Monero using subsidy burning to increase the\n\u003e block size. That approach has various limitations. These were corrected in\n\u003e Greg Maxwell's suggestion to adjust the difficulty/nBits field directly,\n\u003e which also has the added benefit of providing incentive for bidirectional\n\u003e movement during the subsidy period. The description in this email and any\n\u003e errors are my own.\n\u003e\n\u003e On Fri, May 8, 2015 at 12:20 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Between all the flames on this list, several ideas were raised that did\n\u003e\u003e not get much attention. I hereby resubmit these ideas for consideration and\n\u003e\u003e discussion.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of the actual\n\u003e\u003e block sizes over some trailing sampling period. For example, take the\n\u003e\u003e median block size among the most recent 2016 blocks and multiply it by 1.5.\n\u003e\u003e This allows Bitcoin to scale up gradually and organically, rather than\n\u003e\u003e having human beings guessing at what is an appropriate limit.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be determined by a vote of the\n\u003e\u003e miners. Each miner could embed a desired block size limit in the coinbase\n\u003e\u003e transactions of the blocks it publishes. The effective hard block size\n\u003e\u003e limit would be that size having the greatest number of votes within a\n\u003e\u003e sliding window of most recent blocks.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of block-chain\n\u003e\u003e length, so that it can scale up smoothly rather than jumping immediately to\n\u003e\u003e 20 MB. This function could be linear (anticipating a breakdown of Moore's\n\u003e\u003e Law) or quadratic.\n\u003e\u003e\n\u003e\u003e I would be in support of any of the above, but I do not support Mike\n\u003e\u003e Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the\n\u003e\u003e road without actually solving the problem, and it does so in a\n\u003e\u003e controversial (step function) way.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/95998365/attachment.html\u003e"}