Quote from: DeepCryptoanalist3 on June 07, 2014, 02:22:01 PM

Quote from: HunterMinerCrafter on June 07, 2014, 02:06:20 PM

Only if they can overcome the production rate of the other bot miners, though. This is, after all, still a form of 51% attack.

Now there is no complexity growth in block solution task. Without this criteria solutions will become faster and faster. Now bots needs 3 sec to solve a level. With some optimization it will be a fraction of a second. Finally we will came to the point when bot owner will have no aim to share individual blocks among other miners because net lag will be bigger than the block generation time. Bot owners will build series of blocks like 10-100 in a row and throw them into network at once. This is crazy way to go. Complexity threshold should be fixed and tightened to the real time. It should be a race for better and more optimal level solutions.

My point is still valid, even despite the "crazy" outcome. Presumably as one bot miner gets faster and faster the majority of his competition bot miners will get faster and faster as well, and the difficulty of performing the attack will remain relatively consistent.

I don't believe anyone can currently solve blocks (each time) in 3 seconds. Or, rather, I think that even with double-spending attacks the potential gain is not worth the current energy spend to do so. So the only real motivation for throwing this excess of hashing at the network would be to speculate, and I don't expect that some who believes that the value will rise would also attack the network with double-spend, either via your difficulty time warp or via a traditional 51%. To do so would not be very rational.

So, in other words, we could potentially see some silliness with miners pre-solving and batch submitting multiple blocks and so forth, but I would not expect to see these participants doing so as part of an explicit attack, currently. The resulting forks might occasionally be a nuisance to users, but not ultimately detrimental to them. (I'd expect forks to include more or less the same sets of user tx records on both sides of the fork.)