{"type":"rich","version":"1.0","author_name":"npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt","author_url":"https://nostr.ae/npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjt","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-29\n📝 Original message:My current idea:\n\n* There's a scheduled hardcap that goes up over time.\n\n* Miners vote on the blocksize limit within the hardcap, choosing the new\nvotecap. No particular idea for scheduling change. The 2016 block period\nseems a bit long though, in case of sudden peak load.\n(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes\ncounted from block A to block B = block A+X, the change is enacted at block\nC = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a\nreasonable time, such as IMHO 2 days - we need rapid peak adjustment. No\nsuggestion on vote result calculation mechanism.)\n\n* Casting votes are free.\n\n* The mean (average) blocksize over the last time period X is calculated\nfor every block, or at the end of every fixed-length period (depending on\nwhat scheduling is used for votes).\n\n* Creating blocks larger than the mean but below the votecap raises the\ndifficulty target for the miner (and slightly raises the mean for future\nblocks).\n\n* The degree of difficulty raise depends on where between the mean and\nvotecap that the size of the given block is (and it follows that lots of\nvotes for large raise reduces per-extra-Kb penalty, allowing for cheaper\npeak load adjustment if a large miner majority agrees). The degree of\nincrease may be either linear or logarithmic, I've got no suggestion\ncurrently on any particular metric.\n(Some might think this is an easy way for miners to collude to make large\nblocks cheaper. If so, you could commit to only pay fee to miners that\ndon't vote for a block size above the size you accept, as a\ncounter-incentive.)\n\n* Question: When the votecap is lowered, should the calculated mean be\nforced down to follow (forcing a penalty for making blocks close to the\nvotecap straight after the change)? If so, how? Or should it be allowed to\nfall naturally as new blocks with size below the votecap are created?\n\nThis is how miners would pay for actually creating larger blocks, and\nleaves us with three methods of keeping the size in check (hardcap, votecap\nand softcap). The softcap mechanism is then our third check to use if\ndeemed necessary (orphaning valid blocks if considered problematically\nlarge). This third option do not need coordination with miners, they just\nneed to be aware which block size is accepted by the community.\n\nI can't think of any sensible non-miner mechanism of deciding max block\nsize outside of using a community coordinated softcap, anything else will\nnot work reliably. Too hard to measure objectively and judge fairly.\n\nThe community would thus agree on a hardcap schedule in advance, and have\nthe option to threaten orphaning blocks via softfork later on if\ncircumstances would change and the votecap is too large.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150829/a985f3e6/attachment.html\u003e"}