{"type":"rich","version":"1.0","author_name":"npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","author_url":"https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-29\n📝 Original message:On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak \u003cbtcdrak at gmail.com\u003e wrote:\n\u003e On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e Ah, then my mistake. It seemed so similar to an idea that was proposed\n\u003e\u003e before on this mailing list:\n\u003e\u003e\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html\n\u003e\u003e\n\u003e\u003e that my mind just filled in the gaps. I concur -- having miners -- or any\n\u003e\u003e group -- vote on block size is not an intrinsically good thing. The the\n\u003e\u003e original proposal due to Greg Maxwell et al was not a mechanism for \"voting\"\n\u003e\u003e but rather a feedback control that made the maximum block size that which\n\u003e\u003e generated the most fees.\n\u003e\n\u003e Mark and Jorge,\n\u003e\n\u003e I am very glad you have brought up this particular objection because\n\u003e it's something I thought about but was unclear if it was an opinion\n\u003e that would be shared by others. I chose to omit it from the proposal\n\u003e to see if it would come up during peer review.\n\u003e\n\u003e I feel that giving miners a blank cheque to increase blocksize, by any\n\u003e means, goes against a key design of bitcoin's security model. Full\n\u003e nodes keep miners honest by ensuring by validating their blocks. Under\n\u003e any voting-only scheme there is no way for full nodes to keep miners\n\u003e in cheque because miner have free reign to increase the blocksize.\n\u003e\n\u003e This problem can be solved by introducing a hard cap on blocksize. By\n\u003e introducing an upper limit miners now have the freedom to increase\n\u003e blocksize but only within defined parameters.  Remember my proposal\n\u003e allows blocksize to increase and decrease in such a way that miners\n\u003e must collectively agree if they want the size to increase.\n\nThen I only care about the hard cap (for example, to me bip100 is\npractically equivalent to just raise the limit to 32 MB directly).\nMiners can always produce smaller blocks by modifying their local policy.\nSo if we need a maximum that cannot be altered by miners anyway, why\ntake the additional complexity of miners voting on a lower and\nchanging maximum size?\n\n\u003e With respect to the flexicap idea where miners can create a larger\n\u003e block by paying extra difficulty, I believe that proposal has a\n\u003e critical flaw because, as Gavin pointed out, it makes it very\n\u003e expensive (and risky) to include a few extra transactions. I believe\n\u003e it suffers from tragedy of the commons because there is no incentive\n\u003e for the mining community to reach consensus. Each and every block is\n\u003e going to be a gamble, \"should we include a few extra transactions at\n\u003e the risk of losing the block?\".\n\nHow expensive it is depends on the concrete function f(extra_nBits) =\nextra_size_allowed\nBut the goal of that proposal is not to raise the size maximum\npermanently, but rather temporarily allow bigger blocks when there are\nspikes in demand (ie many fees to collect in unconfirmed\ntransactions).\nYes miners will ask that question to themselves, and the answer will\ndepend on the concrete function and on the fees of those extra\ntransactions.\nThe miner paying for the costs will get the gains: no tragedy of the\ncommons here.\n\n\u003e Under my proposal miners can\n\u003e collectively agree to change the blocksize. Let's say they want a 10%\n\u003e increase, they can collude together to make that increase and once\n\u003e reached, it remains until they want to change it again. Yet, the upper\n\u003e hard limit keeps the ultimate control of the maximum block size\n\u003e squarely in the hands of full nodes.\n\nI believe the tragedy of the commons actually happens with your\nproposal. Why would I pay alone for something that benefits all\nminers?\n\n\u003e An alternative methodology to voting in the coinbase would be to\n\u003e change the vote to be the blocksize itself\n\u003e\n\u003e 1. miners pay extra difficulty to create a larger block.\n\u003e 2. every 2016 blocks the average or median of the last 2016 blocks is\n\u003e calculated and becomes the new maximum blocksize limit.\n\u003e\n\u003e This would retain incentive to collude to increase blocksize, as well\n\u003e as the property of costing to increase while being free to propose\n\u003e decrease.\n\nThis seems to solve the tragedy of the commons problem with your\ncurrent proposal.\nIt would be like flexcap but instead of the change in size being\ntemporary, it affects the next maximum size permanently.\nOne thing to worry about is miners filling blocks with\npay-to-themselves garbage to avoid reducing the size when they don't\nhave enough attractive transactions to include (ie it may not be free\nfor the network for miners to vote on \"maintain current size\").\n\n\u003e It would still require an upper blocksize limit in order for full\n\u003e nodes to retain control. Without an upper limit, any proposal is going\n\u003e to break the security model as full nodes give up some oversight\n\u003e control over miners.\n\u003e\n\u003e Another way of looking at these ideas is we're raising blocksize hard\n\u003e limit (to 8MB or whatever is decided), but making a soft of \"softer\"\n\u003e or inner limit part of consensus. Such a concept is not really\n\u003e departing from the current idea of a soft limit except to make it\n\u003e consensus enforced. Obviously it's not identical, but I think you can\n\u003e see the similarities.\n\u003e\n\u003e Does that make sense?\n\nI still don't see the point in having a lower moving size maximum.\nIf 8 MB is mining-centralization-safe, let's move directly to 8 MB\nwithout adding this seemingly useless extra complexity.\nIf it's not, mining voting on a lower moving maximum won't make it safer.\n\nOnce we have more objective tools (centralization metrics, simulators,\netc...) to determine whether or not a block size is\nmining-centralization-safe for a given point in time (looking at\ncurrent centralization and current technology available), I don't see\nthe problem with repeating the equivalent of bip102 periodically\n(every 2 years?) to adapt the size to better technology or lower\nmining centralization.\nIt would be also helpful to have a tool to somehow measure \"size\nincrease urgency\" (ie right now free transactions get mined and blocks\naren't full or close to be full, I don't think the current general\nsense of urgency on this matter is justified).\n\nWith all respect, I believe bip100 and this proposal are\nover-engineering; and bip101 and bip103 (pieter's) are\noverly-optimistic (in their exponential technological growth\nassumptions)."}