{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-09\n📝 Original message:On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e wrote:\n\u003e These rules create an incentive environment where raising the block size has\n\u003e a real cost associated with it: a more difficult hashcash target for the\n\u003e same subsidy reward. For rational miners that cost must be counter-balanced\n\u003e by additional fees provided in the larger block. This allows block size to\n\u003e increase, but only within the confines of a self-supporting fee economy.\n\u003e\n\u003e When the subsidy goes away or is reduced to an insignificant fraction of the\n\u003e block reward, this incentive structure goes away. Hopefully at that time we\n\u003e would have sufficient information to soft-fork set a hard block size\n\u003e maximum. But in the mean time, the block size limit controller constrains\n\u003e the maximum allowed block size to be within a range supported by fees on the\n\u003e network, providing an emergency relief valve that we can be assured will\n\u003e only be used at significant cost.\n\nThough I'm a fan of this class of techniques(*) and think using something\nin this space is strictly superior to not, and I think it makes larger\nsizes safer long term;  I do not think it adequately obviates the need\nfor a hard upper limit for two reasons:\n\n(1) for software engineering and operational reasons it is very\ndifficult to develop, test for, or provision for something without\nknowing limits. There would in fact be hard limits on real deployments\nbut they'd be opaque to their operators and you could easily imagine\nthe network forking by surprise as hosts crossed those limits.\n\n(2)  At best this approach mitigates the collective action problem between\nminers around fees;  it does not correct the incentive alignment between\nminers and everyone else (miners can afford huge node costs because they\nhave income; but the full-node-using-users that need to exist in plenty\nto keep miners honest do not), or the centralization pressures (N miners\ncan reduce their storage/bandwidth/cpu costs N fold by centralizing).\n\nA dynamic limit can be combined with a hard upper to at least be no\nworse than a hard upper with respect to those two points.\n\n\nAnother related point which has been tendered before but seems to have\nbeen ignored is that changing how the size limit is computed can help\nbetter align incentives and thus reduce risk.  E.g. a major cost to the\nnetwork is the UTXO impact of transactions, but since the limit is blind\nto UTXO impact a miner would gain less income if substantially factoring\nUTXO impact into its fee calculations; and without fee impact users have\nlittle reason to optimize their UTXO behavior.   This can be corrected\nby augmenting the \"size\" used for limit calculations.   An example would\nbe tx_size = MAX( real_size \u003e\u003e 1,  real_size + 4*utxo_created_size -\n3*utxo_consumed_size).   The reason for the MAX is so that a block\nwhich cleaned a bunch of big UTXO could not break software by being\nsuper large, the utxo_consumed basically lets you credit your fees by\ncleaning the utxo set; but since you get less credit than you cost the\npressure should be downward but not hugely so. The 1/2, 4, 3 I regard\nas parameters which I don't have very strong opinions on which could be\nset based on observations in the network today (e.g. adjusted so that a\nnormal cleaning transaction can hit the minimum size).  One way to think\nabout this is that it makes it so that every output you create \"prepays\"\nthe transaction fees needed to spend it by shifting \"space\" from the\ncurrent block to a future block. The fact that the prepayment is not\nperfectly efficient reduces the incentive for miners to create lots of\nextra outputs when they have room left in their block in order to store\nspace to use later [an issue that is potentially less of a concern with a\ndynamic size limit].  With the right parameters there would never be such\nat thing as a dust output (one which costs more to spend than its worth).\n\n(likewise the sigops limit should be counted correctly and turned into\nsize augmentation (ones that get run by the txn); which would greatly\nsimplify selection rules: maximize income within a single scalar limit)\n\n(*) I believe my currently favored formulation of general dynamic control\nidea is that each miner expresses in their coinbase a preferred size\nbetween some minimum (e.g. 500k) and the miner's effective-maximum;\nthe actual block size can be up to the effective maximum even if the\npreference is lower (you're not forced to make a lower block because you\nstated you wished the limit were lower).  There is a computed maximum\nwhich is the 33-rd percentile of the last 2016 coinbase preferences\nminus computed_max/52 (rounding up to 1) bytes-- or 500k if thats\nlarger. The effective maximum is X bytes more, where X on the range\n[0, computed_maximum] e.g. the miner can double the size of their\nblock at most. If X \u003e 0, then the miners must also reach a target\nF(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---\nso the maximum penalty is 2, with a quadratic shape;  for a given mempool\nthere will be some value that maximizes expected income.  (obviously all\nimplemented with precise fixed point arithmetic).   The percentile is\nintended to give the preferences of the 33% least preferring miners a\nveto on increases (unless a majority chooses to soft-fork them out). The\nminus-comp_max/52 provides an incentive to slowly shrink the maximum\nif its too large-- x/52 would halve the size in one year if miners\nwere doing the lowest difficulty mining. The parameters 500k/33rd,\n-computed_max/52 bytes, and f(x)  I have less strong opinions about;\nand would love to hear reasoned arguments for particular parameters."}