{"type":"rich","version":"1.0","author_name":"npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2d","author_url":"https://nostr.ae/npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2d","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-12-11\n📝 Original message:What's most likely to happen is miners will max out the blocks they\nmine simply to try and get as many transaction fees as possible like\nthey are doing right now(there will be a backlog of transactions at\nany block size). Having the block size double every year would likely\ncause major problems and this proposal allows over a 7x increase it\nseems.\n\nThe main problem with this proposal I think is that users effectively\nhave no way to stop the miners from increasing block size\ncontinuously.\n\nOn Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e On Sun, Dec 11, 2016 at 12:11 PM, s7r \u003cs7r at sky-ip.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e This is an incentive, if few miners agree to create a large conglomerate\n\u003e\u003e that will ultimately control the network.\n\u003e\u003e\n\u003e\u003e You miss something obvious that makes this attack actually free of cost.\n\u003e\u003e Nothing will \"cost them more in transaction fees\". A miner can create\n\u003e\u003e thousands of transactions paying to himself, and not broadcast them to\n\u003e\u003e the network, but hold them and include them in the blocks he mines. The\n\u003e\u003e fees are collected by him because transactions are included in a block\n\u003e\u003e that he mined and the left amount is in another wallet of the same\n\u003e\u003e person. Repeat this continuously to fill blocks.\n\u003e\n\u003e\n\u003e No, that wasn't overlooked. Miners could indeed stuff their own blocks for\n\u003e free, but they can't stuff blocks mined by others for free.\n\u003e\n\u003e In the hypothetical scenario where there is a single mining pool which mines\n\u003e most (if not all) of the blocks, we would have much larger problems than\n\u003e their ability to raise the max block size gradually. Even if they were able\n\u003e to fill 100% of the blocks for an entire year, the max block size for that\n\u003e 2016 block period would be 7.25MB (not accounting for SegWit). After the\n\u003e whole year they would have made no extra profit vs doing nothing. And as\n\u003e soon as they stopped this scheme, block size would spring back to it's\n\u003e natural level.\n\u003e\n\u003e The good news is, this scenario has never happened and even when we've come\n\u003e remotely close (when ASICs first shipped), the situation was temporary. The\n\u003e odds of this happening in the future and persisting long enough to have any\n\u003e major effect with Block75 are very close to zero.\n\u003e\n\u003e\u003e\n\u003e\u003e Topology and bandwidth speed / hash rate of the network cannot be\n\u003e\u003e controlled - if we make assumptions about these it might have terrible\n\u003e\u003e consequences.\n\u003e\u003e\n\u003e\u003e Even if we take in consideration that bandwidth will only grow and disk\n\u003e\u003e space will only cost less (which is not something we can safely assume,\n\u003e\u003e by the way) the hard limit max. block size cannot grow to unlimited\n\u003e\u003e value (even if the growth happens over time). There is also a validation\n\u003e\u003e cost in time for each block, for the health of the network any node\n\u003e\u003e should be able to download _and_ validate a block, before next block\n\u003e\u003e gets mined.\n\u003e\u003e\n\u003e\u003e You said in another post that a permanent solution is preferred, rather\n\u003e\u003e than kicking the can down the road. I fully agree, as well as many\n\u003e\u003e others reading this list, but the permanent solution doesn't necessarily\n\u003e\u003e have to be increasing the max block size dynamically.\n\u003e\n\u003e\n\u003e Increasing *and* decreasing max block size dynamically. Block75 is\n\u003e self-correcting, whereas any solution with hardcoded limits can't correct\n\u003e without human intervention and would rely on our ability to predict the\n\u003e future (which as you pointed out, we can't do). Therefore, any solution\n\u003e that's not dynamic cannot be permanent.\n\u003e\n\u003e Additionally, the frequent and gradual changes in max block size would allow\n\u003e us to see any consequences well in advance (years probably).\n\u003e\n\u003e\u003e\n\u003e\u003e If you think about it the other way around, dynamically growing the max\n\u003e\u003e block size is also kicking the can down the road ... just without having\n\u003e\u003e to touch it and get dust on the boot ;)\n\u003e\n\u003e\n\u003e Not having to touch it again = permanent solution. ;)\n\u003e\n\u003e It would be helpful if some others would run the numbers on how Block75\n\u003e would adjust the block size over time:\n\u003e\n\u003e new max block size = 1000kb + (average block size over last 2016 blocks -\n\u003e 750kb)\n\u003e\n\u003e -t.k.\n\u003e\n\u003e\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\n\u003e"}