{"type":"rich","version":"1.0","author_name":"npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","author_url":"https://nostr.ae/npub1kc0zulxt7j4a0ayhzhrz7jk84y7tm4026qcky7w97hlfkxxap24qnwjfw4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-29\n📝 Original message:I am quite skeptical about any pay-to-increase proposal because it is \ndifficult to predict the game dynamics and determine the right amount of \npenalty. But anyway, here is my response to your revised proposal:\n\n1. I agree with you that there should be a cap in the rate of change, \nand also the maximum possible size. This is already part of BIP100\n\n2. Requiring a higher difficulty is bad for everyone:\n  a) it increases the variance of the miner;\n  b) average confirmation time for all tx are increased. It may even \ncause a feedback: many tx in mempool -\u003e increase block size -\u003e wait \nlonger for confirmation -\u003e more tx in mempool;\n  c) difficulty of the next round will be decreased, leading to a greater \nfluctuation in confirmation time.\n\nInstead, you should require miners to burn their coinbase reward. This \nis effectively same as higher difficulty but is good for everyone: a) \nmining variance and confirmation time unchanged; b) all bitcoin holders \nbecome relatively richer\n\nIf you don't want to burn any bitcoin, you may require the miner the \nsend to penalty to \u003c840000 + current height\u003e OP_CHECKLOCKTIMEVERIFY, \nwhich will subsidize the mining when the block reward drops below 1 BTC\n\n3. It is a better idea to allow mining of a bigger block immediately, \nwhich reduces (but not eliminates) the problem of tragedy of the \ncommons. However, you can't use the blocksize as the vote. Mining an \nempty block doesn't mean the miner wants to decrease the block size to \n200 bytes. That will just encourage some miners to fill up a block with \ngarbage which does no good for anyone. Therefore, you need to look at \nboth the actual block size and the coinbase vote, and always take the \nbigger value to determine the penalty and the max block size of next \nround. If a miner includes nothing in the coinbase, it should be \nconsider as a vote for the current max block size.\n\n\n\nBtc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到:\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 \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\u003e \n\u003e I believe the idea of a hard upper limit has become rather politicised\n\u003e but is essential to the security model of bitcoin.\n\u003e \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?\". 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\u003e \n\u003e Whilst the exact number may be up for discussion, I would propose an\n\u003e initial upper limit of 8MB, so under my proposal the blocksize would\n\u003e be flexible between 1MB and 8MB.\n\u003e \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\u003e \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\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}