Quote from: Spiky on September 03, 2014, 08:29:57 AM

1) No matter how clever this bot is, he still requires to enumerate thousands of maps. We should make map generation really slow process that require a lot of hash work (you can take some average pc and tune this alghorithm so that it require 2-3 sec on average). It would definitelly be inconvinient for people but we must do it. Don't invent complex anti-warp algorithm etc, just make this hash work constant and huge.

The real problem here is that what is "2-3 sec on average" worth of work for an "average pc" might be virtually no work at all for a gpu/asic. What is 2-3 seconds of work for an asic might take hours on an average pc. It can't really be constant, it needs to adapt to network conditions.

The anti-warp is not complex, it is precisely what you're asking for but without the "constant and huge" part. It is just a dynamic slowdown to map generation. (EDIT: I should clarify that the "constant" part is intentionally avoided, and the "huge" part is what we're now trying to improve. The problem we currently are facing is basically that the anti-warp slowdown isn't "getting bigger enough, fast enough" to also be useful as an anti-bot mechanism, particularly with one bot outperforming so significantly.)

Quote

2) We should slow down solving process too by requring around 1 sec of hash work every 3-5 seconds of playing and mix founded nonces in the physics (alter velocity, acceleration etc) (this changes should be significant, it should be impossible to ignore them). I know the game will hang sometimes (when hash is not ready yet), but I think we can accept it. Also this would require us to enlarge proof of work significantly (we'll have to save our hash nonces somewhere) but this step is really neccessary.

While I tend to agree that this would be quite a good solution, I have yet to find a reasonable way to actually execute it. If the work "mixed in" has too much impact on the physics it makes for some unpleasant experience for a human player. If it does not have enough impact then bots can simply ignore the perturbations and solve without the extra work and just "double check" their solutions for validity with the work cycles added back in.

Further, collision timing is entirely unpredictable so in any case this means frame-rates would become uneven for humans, which creates quite a jarring experience.

I'd love to see some dynamic work requirement directly "baked into traversal" in this fashion, but I simply can't seem to find a way to do it without (significantly) adversely impacting the game itself.

Quote

I've believed and still believe that these two steps will kill all current and future bots for months or even years.

I'm not entirely sure. Because this would have to be a dynamic scale, I worry that it would just create a second sort of "map restarts problem" by pushing humans' frame-rates absurdly low.

Quote

You will probably not be able to mine with your bot too, but you have already proved that you don't care too much about it.

Again the goal is not, has never been, and will never be to cut out bots entirely. To do so would probably be nearly impossible, and would certainly be dangerous. Both of these principles were demonstrated nicely this week. We need to get to a state where the challenge is, all around, well balanced between machine and human so that we can have a diverse set of bots functioning to offer around-the-clock network security but without too much impact on human mining.