{"type":"rich","version":"1.0","author_name":"npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch","author_url":"https://nostr.ae/npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-12-11\n📝 Original message:On Sun, Dec 11, 2016 at 12:11 PM, s7r \u003cs7r at sky-ip.org\u003e wrote:\n\n\u003e\n\u003e This is an incentive, if few miners agree to create a large conglomerate\n\u003e that will ultimately control the network.\n\u003e\n\u003e You miss something obvious that makes this attack actually free of cost.\n\u003e Nothing will \"cost them more in transaction fees\". A miner can create\n\u003e thousands of transactions paying to himself, and not broadcast them to\n\u003e the network, but hold them and include them in the blocks he mines. The\n\u003e fees are collected by him because transactions are included in a block\n\u003e that he mined and the left amount is in another wallet of the same\n\u003e person. Repeat this continuously to fill blocks.\n\u003e\n\nNo, that wasn't overlooked. Miners could indeed stuff their own blocks for\nfree, but they can't stuff blocks mined by others for free.\n\nIn the hypothetical scenario where there is a single mining pool which\nmines most (if not all) of the blocks, we would have much larger problems\nthan their ability to raise the max block size gradually. Even if they were\nable to fill 100% of the blocks for an entire year, the max block size for\nthat 2016 block period would be 7.25MB (not accounting for SegWit). After\nthe whole year they would have made no extra profit vs doing nothing. And\nas soon as they stopped this scheme, block size would spring back to it's\nnatural level.\n\nThe good news is, this scenario has never happened and even when we've come\nremotely close (when ASICs first shipped), the situation was temporary. The\nodds of this happening in the future and persisting long enough to have any\nmajor effect with Block75 are very close to zero.\n\n\n\u003e Topology and bandwidth speed / hash rate of the network cannot be\n\u003e controlled - if we make assumptions about these it might have terrible\n\u003e consequences.\n\u003e\n\u003e Even if we take in consideration that bandwidth will only grow and disk\n\u003e space will only cost less (which is not something we can safely assume,\n\u003e by the way) the hard limit max. block size cannot grow to unlimited\n\u003e value (even if the growth happens over time). There is also a validation\n\u003e cost in time for each block, for the health of the network any node\n\u003e should be able to download _and_ validate a block, before next block\n\u003e gets mined.\n\u003e\n\u003e You said in another post that a permanent solution is preferred, rather\n\u003e than kicking the can down the road. I fully agree, as well as many\n\u003e others reading this list, but the permanent solution doesn't necessarily\n\u003e have to be increasing the max block size dynamically.\n\u003e\n\nIncreasing *and* decreasing max block size dynamically. Block75 is\nself-correcting, whereas any solution with hardcoded limits can't correct\nwithout human intervention and would rely on our ability to predict the\nfuture (which as you pointed out, we can't do). Therefore, any solution\nthat's not dynamic cannot be permanent.\n\nAdditionally, the frequent and gradual changes in max block size would\nallow us to see any consequences well in advance (years probably).\n\n\n\u003e If you think about it the other way around, dynamically growing the max\n\u003e block size is also kicking the can down the road ... just without having\n\u003e to touch it and get dust on the boot ;)\n\n\nNot having to touch it again = permanent solution. ;)\n\nIt would be helpful if some others would run the numbers on how Block75\nwould adjust the block size over time:\n\nnew max block size = 1000kb + (average block size over last 2016 blocks -\n750kb)\n\n-t.k.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/cb598cfa/attachment.html\u003e"}