{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-10\n📝 Original message:Let me make sure I understand this proposal:\n\nOn Fri, May 8, 2015 at 11:36 PM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e (*) I believe my currently favored formulation of general dynamic control\n\u003e idea is that each miner expresses in their coinbase a preferred size\n\u003e between some minimum (e.g. 500k) and the miner's effective-maximum;\n\u003e the actual block size can be up to the effective maximum even if the\n\u003e preference is lower (you're not forced to make a lower block because you\n\u003e stated you wished the limit were lower).  There is a computed maximum\n\u003e which is the 33-rd percentile of the last 2016 coinbase preferences\n\u003e minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats\n\u003e larger. The effective maximum is X bytes more, where X on the range\n\u003e [0, computed_maximum] e.g. the miner can double the size of their\n\u003e block at most. If X \u003e 0, then the miners must also reach a target\n\u003e F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---\n\u003e so the maximum penalty is 2, with a quadratic shape;  for a given mempool\n\u003e there will be some value that maximizes expected income.  (obviously all\n\u003e implemented with precise fixed point arithmetic).   The percentile is\n\u003e intended to give the preferences of the 33% least preferring miners a\n\u003e veto on increases (unless a majority chooses to soft-fork them out). The\n\u003e minus-comp_max/52 provides an incentive to slowly shrink the maximum\n\u003e if its too large-- x/52 would halve the size in one year if miners\n\u003e were doing the lowest difficulty mining. The parameters 500k/33rd,\n\u003e -computed_max/52 bytes, and f(x)  I have less strong opinions about;\n\u003e and would love to hear reasoned arguments for particular parameters.\n\u003e\n\nI'm going to try to figure out how much transaction fee a transaction would\nhave to pay to bribe a miner to include it. Greg, please let me know if\nI've misinterpreted the proposed algorithm. And everybody, please let me\nknow if I'm making a bone-headed mistake in how I'm computing anything:\n\nLets say miners are expressing a desire for 600,000 byte blocks in their\ncoinbases.\n\ncomputed_max = 600,000 - 600,000/52 = 588,462 bytes.\n  --\u003e this is about 23 average-size (500-byte) transactions less than\n600,000.\neffective_max = 1,176,923\n\nLets say I want to maintain status quo at 600,000 bytes; how much penalty\ndo I have?\n((600,000-588,462)/588,462)^2 + 1 = 1.00038\n\nHow much will that cost me?\nThe network is hashing at 310PetaHash/sec right now.\nTakes 600 seconds to find a block, so 186,000PH per block\n186,000 * 0.00038 = 70 extra PH\n\nIf it takes 186,000 PH to find a block, and a block is worth 25.13 BTC\n(reward plus fees), that 70 PH costs:\n(25.13 BTC/block / 186,000 PH/block) * 70 PH = 0.00945 BTC\nor at $240 / BTC:  $2.27\n\n... so average transaction fee will have to be about ten cents ($2.27\nspread across 23 average-sized transactions) for miners to decide to stay\nat 600K blocks. If they fill up 588,462 bytes and don't have some\nten-cent-fee transactions left, they should express a desire to create a\n588,462-byte-block and mine with no penalty.\n\nIs that too much?  Not enough?  Average transaction fees today are about 3\ncents per transaction.\nI created a spreadsheet playing with the parameters:\n\nhttps://docs.google.com/spreadsheets/d/1zYZfb44Uns8ai0KnoQ-LixDwdhqO5iTI3ZRcihQXlgk/edit?usp=sharing\n\n\"We\" could tweak the constants or function to get a transaction fee we\nthink is reasonable... but we really shouldn't be deciding whether\ntransaction fees are too high, too low, or just right, and after thinking\nabout this for a while I think any algorithm that ties difficulty to block\nsize is just a complicated way of dictating minimum fees.\n\nAs for some other dynamic algorithm: OK with me. How do we get consensus on\nwhat the best algorithm is? I'm ok with any \"don't grow too quickly, give\nsome reasonable-percentage-minority of miners the ability to block further\nincreases.\"\n\nAlso relevant here:\n\"The curious task of economics is to demonstrate to men how little they\nreally know about what they imagine they can design.\" - Friedrich August\nvon Hayek\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150510/481dae92/attachment.html\u003e"}