{"type":"rich","version":"1.0","author_name":"npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","author_url":"https://nostr.ae/npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-29\n📝 Original message:On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Ah, then my mistake. It seemed so similar to an idea that was proposed\n\u003e before on this mailing list:\n\u003e\n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html\n\u003e\n\u003e that my mind just filled in the gaps. I concur -- having miners -- or any\n\u003e group -- vote on block size is not an intrinsically good thing. The the\n\u003e original proposal due to Greg Maxwell et al was not a mechanism for \"voting\"\n\u003e but rather a feedback control that made the maximum block size that which\n\u003e generated the most fees.\n\nMark and Jorge,\n\nI am very glad you have brought up this particular objection because\nit's something I thought about but was unclear if it was an opinion\nthat would be shared by others. I chose to omit it from the proposal\nto see if it would come up during peer review.\n\nI feel that giving miners a blank cheque to increase blocksize, by any\nmeans, goes against a key design of bitcoin's security model. Full\nnodes keep miners honest by ensuring by validating their blocks. Under\nany voting-only scheme there is no way for full nodes to keep miners\nin cheque because miner have free reign to increase the blocksize.\n\nThis problem can be solved by introducing a hard cap on blocksize. By\nintroducing an upper limit miners now have the freedom to increase\nblocksize but only within defined parameters.  Remember my proposal\nallows blocksize to increase and decrease in such a way that miners\nmust collectively agree if they want the size to increase.\n\nI believe the idea of a hard upper limit has become rather politicised\nbut is essential to the security model of bitcoin.\n\nWith respect to the flexicap idea where miners can create a larger\nblock by paying extra difficulty, I believe that proposal has a\ncritical flaw because, as Gavin pointed out, it makes it very\nexpensive (and risky) to include a few extra transactions. I believe\nit suffers from tragedy of the commons because there is no incentive\nfor the mining community to reach consensus. Each and every block is\ngoing to be a gamble, \"should we include a few extra transactions at\nthe risk of losing the block?\". Under my proposal miners can\ncollectively agree to change the blocksize. Let's say they want a 10%\nincrease, they can collude together to make that increase and once\nreached, it remains until they want to change it again. Yet, the upper\nhard limit keeps the ultimate control of the maximum block size\nsquarely in the hands of full nodes.\n\nWhilst the exact number may be up for discussion, I would propose an\ninitial upper limit of 8MB, so under my proposal the blocksize would\nbe flexible between 1MB and 8MB.\n\nAn alternative methodology to voting in the coinbase would be to\nchange the vote to be the blocksize itself\n\n1. miners pay extra difficulty to create a larger block.\n2. every 2016 blocks the average or median of the last 2016 blocks is\ncalculated and becomes the new maximum blocksize limit.\n\nThis would retain incentive to collude to increase blocksize, as well\nas the property of costing to increase while being free to propose\ndecrease.\n\nIt would still require an upper blocksize limit in order for full\nnodes to retain control. Without an upper limit, any proposal is going\nto break the security model as full nodes give up some oversight\ncontrol over miners.\n\nAnother way of looking at these ideas is we're raising blocksize hard\nlimit (to 8MB or whatever is decided), but making a soft of \"softer\"\nor inner limit part of consensus. Such a concept is not really\ndeparting from the current idea of a soft limit except to make it\nconsensus enforced. Obviously it's not identical, but I think you can\nsee the similarities.\n\nDoes that make sense?"}