rich1.0npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6https://nostr.ae/npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6njumphttps://nostr.ae📅 Original date posted:2016-12-11 📝 Original message:"You miss something obvious that makes this attack actually free of cost. Nothing will "cost them more in transaction fees". A miner can create thousands of transactions paying to himself, and not broadcast them to the network, but hold them and include them in the blocks he mines. The fees are collected by him because transactions are included in a block that he mined and the left amount is in another wallet of the same person. Repeat this continuously to fill blocks." This is easily detectable as long as the network isn't heavily partitioned(which is an assumption we make today in order for transaction propagation to work reliably as well as for xThin and CompactBlocks to work effectively to reduce block transmission time). Other miners would have an incentive to intentionally orphan blocks that contained a large number of transactions that their nodes were unaware of. I don't think this sort of attack would last long. Even later when subsidies are drastically reduced, you would still lose out on significant genuine fee revenue if your orphan rate increased even 10%(one out of ten of your poison blocks intentionally orphaned by another miner). On Dec 11, 2016 11:12 AM, "s7r via bitcoin-dev" < bitcoin-dev at lists.linuxfoundation.org> wrote: t. khan wrote: > Miners 'gaming' the Block75 system - > There is no financial incentive for miners to attempt to game the > Block75 system. Even if it were attempted and assuming the goal was to > create bigger blocks, the maximum possible increase would be 25% over > the previous block size. And, that size would only last for two weeks > before readjusting down. It would cost them more in transaction fees to > stuff the network than they could ever make up. To game the system, > they'd have to game it forever with no possibility of profit. > This is an incentive, if few miners agree to create a large conglomerate that will ultimately control the network. You miss something obvious that makes this attack actually free of cost. Nothing will "cost them more in transaction fees". A miner can create thousands of transactions paying to himself, and not broadcast them to the network, but hold them and include them in the blocks he mines. The fees are collected by him because transactions are included in a block that he mined and the left amount is in another wallet of the same person. Repeat this continuously to fill blocks. > Blocks would get too big - > Eventually, blocks would get too big, but only if bandwidth stopped > increasing and the cost of disk space stopped decreasing. Otherwise, the > incremental adjustments made by Block75 (especially in combination with > SegWit) wouldn't break anyone's connection or result in significantly > more orphaned blocks. > Topology and bandwidth speed / hash rate of the network cannot be controlled - if we make assumptions about these it might have terrible consequences. Even if we take in consideration that bandwidth will only grow and disk space will only cost less (which is not something we can safely assume, by the way) the hard limit max. block size cannot grow to unlimited value (even if the growth happens over time). There is also a validation cost in time for each block, for the health of the network any node should be able to download _and_ validate a block, before next block gets mined. You said in another post that a permanent solution is preferred, rather than kicking the can down the road. I fully agree, as well as many others reading this list, but the permanent solution doesn't necessarily have to be increasing the max block size dynamically. If you think about it the other way around, dynamically growing the max block size is also kicking the can down the road ... just without having to touch it and get dust on the boot ;) _______________________________________________ bitcoin-dev mailing list bitcoin-dev at lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/ba48b60f/attachment-0001.html>