[ANN][MOTO] Motocoin

[HunterMinerCrafter]

There were several retargets and this bot still generates at this insane speed. Seems that additional work required to generate maps doesn't affect him.

I'm looking into potential bugs.  There probably is one.

I think he may have added more hardware, and/or changed enumeration strategy.

So as we can see the adding some proof-of-work to generation map isn't usefull?? Is there some method to not to do that proof-of-work? Is now some "proof-of-work to generate map" exist?

You misunderstand the subtle subtext of what WIll and I are saying, I suspect.  The work requirement is not probably not being properly enforced.  (EDIT: Removed an incorrect explanation.)

If we get the anti-warp working correctly, this bot is done for.

[HunterMinerCrafter]

So now we have a question to be answered.

We have two options:

A) Immediate hard-fork ASAP with a third hard-coded fork point with the bug fixed. (We're on block 189042 as of this writing)
B) Fix the bug in the wallet unconditionally, which will invalidate any transactions since the warp began.  This would effectively be a sort of rollback.

Personally, I think the "obvious answer" is A, but I'm interested in hearing a pitch for B.

[Vz]

So now we have a question to be answered.

We have two options:

A) Immediate hard-fork ASAP with a third hard-coded fork point with the bug fixed. (We're on block 189042 as of this writing)
B) Fix the bug in the wallet unconditionally?, which will invalidate any transactions since the warp began.  This would effectively be a sort of rollback.

Personally, I think the "obvious answer" is A, but I'm interested in hearing a pitch for B.

Sorry I bad in english and some times don't understand well(
Since the warp it is since what? since the bot start? maybe the c-cex will have some problems from that.. sime kind of double spending..

So the A option will be the best.. since 190000 if we can?

[HunterMinerCrafter]

So our silent bot miner is most certainly watching the thread.  Hello!

They appear to have found two bugs in my code, both of which are pretty obvious in retrospect.  One seems to avoid the work requirement entirely, which I am still investigating some aspects of. (EDIT: Removed incorrect explanation)
(EDIT2: Both explanations were incorrect.)

In any case his solver really is just that awesome, so even when we fix up the paywork code we will probably still maintain a work debt, and will have some risk (much smaller than before, for sure) of a work credit attack being possible until we get a work curve measurement of a similarly capable solver, but at least the map will not be flickering and we won't just be staring at the black screen of death.

[HunterMinerCrafter]

Sorry I bad in english and some times don't understand well(
Since the warp it is since what? since the bot start?

I haven't looked at exactly what the fork point would be, yet (busy testing the fix and trying to figure out how the one bug got through test in the first place) but I'd guess this would revert us all the way back to somewhere between 182000 and 184000.  I don't know how many non-coinbase tx would get undone, but we could look on the chain, I'm guessing it would not be much.

maybe the c-cex will have some problems from that.. sime kind of double spending..

Yes, they would probably be the only ones to stand to lose much.  On the other hand, it is precisely this reason that I think the A option is the "obvious" option.

So the A option will be the best.. since 190000 if we can?

At the rate the bot is going 190000 might be too soon for me to even get builds together.  189160 already, now.

[mriulian]

hi, i installed the wallet and when i click on play to mine - nothing is happening...i have windows xp, i wallet is updated with that blocks..anyone can help me?

This happened to me. You need to install these x86 run times. Even if your computer is x64 you need x86.
http://www.microsoft.com/en-us/download/details.aspx?id=40784

Hi, i just installed x86 but still nothin.i ll try to reinstal my operating sistem. Maybe on w7 x32 sill work

[Vz]

hi, i installed the wallet and when i click on play to mine - nothing is happening...i have windows xp, i wallet is updated with that blocks..anyone can help me?

This happened to me. You need to install these x86 run times. Even if your computer is x64 you need x86.
http://www.microsoft.com/en-us/download/details.aspx?id=40784

Hi, i just installed x86 but still nothin.i ll try to reinstal my operating sistem. Maybe on w7 x32 sill work

Try.. on win7 x32 it start and work on 3 my PC.. if all will gone absolutly bad.. try ubuntu)

[HunterMinerCrafter]

I think I initially misunderstood one aspect of the bug, and am now actually wondering if there is much of a "bug" at all.

Like normal difficulty, the anti-warp target is restricted to not adjusting by more than 25% of the amount relative to the target time span, any time a new target is set.  Because of this, the anti-warp will kick in relatively slowly.  I had mentioned earlier in the thread that we probably want to establish a separate and faster re-target interval for the anti-warp itself.  In the hurry to get the chain hashing again, the patch was pushed without this aspect being given analysis or even much more thought, under an assumption that no bot would be "good enough" to create such a drastic warping effect so quickly.  Evidently, I was very wrong about this assumption.

However, the time warp work requirement is actually targeting "correctly."  Because of this, the 7 bit collision requirement on maps is expected.  It will just take us a while for the target to catch up with this impressively high hash rate, as things stand.

[e1ghtSpace]

I think I initially misunderstood one aspect of the bug, and am now actually wondering if there is much of a "bug" at all.

Like normal difficulty, the anti-warp target is restricted to not adjusting by more than 25% of the amount relative to the target time span, any time a new target is set.  Because of this, the anti-warp will kick in relatively slowly.  I had mentioned earlier in the thread that we probably want to establish a separate and faster re-target interval for the anti-warp itself.  In the hurry to get the chain hashing again, the patch was pushed without this aspect being given analysis or even much more thought, under an assumption that no bot would be "good enough" to create such a drastic warping effect so quickly.  Evidently, I was very wrong about this assumption.

However, the time warp work requirement is actually targeting "correctly."  Because of this, the 7 bit collision requirement on maps is expected.  It will just take us a while for the target to catch up with this impressively high hash rate, as things stand.

You said before there were 2 bugs, was this both of the bugs (even though this isn't a bug at all) or is there another one.

[HunterMinerCrafter]

You said before there were 2 bugs, was this both of the bugs (even though this isn't a bug at all) or is there another one.

It turns out that I was probably wrong. I actually don't see any bug.  (I'm still keeping an eye out for one, though.)  It is just the matter of the anti-warp target being updated only every 2k blocks, as far as I can tell.

We should probably still go ahead and fork again to increase this targeting frequency. 

TT and other directly game-related aspects will not need to change, this will only affect how frequently the anti-warp target updates.

[e1ghtSpace]

You said before there were 2 bugs, was this both of the bugs (even though this isn't a bug at all) or is there another one.

It turns out that I was probably wrong. I actually don't see any bug.  (I'm still keeping an eye out for one, though.)  It is just the matter of the anti-warp target being updated only every 2k blocks, as far as I can tell.

We should probably still go ahead and fork again to increase this targeting frequency. 

TT and other directly game-related aspects will not need to change, this will only affect how frequently the anti-warp target updates.

Alright, that should be very easy to implement. Do you have an ETA?

[HunterMinerCrafter]

Alright, that should be very easy to implement.

Yes, it would basically be just a somewhat "redundant" patch to GetNextWorkRequired, nothing more.  It is, in a sense, a change we just made once, already.

Probably I will bump the version numbers as well, just for fun.

I'm still trying to decide on a good interval.  I thought I had a reasonable way to peg a precise number, but it turns out it was not actually better, for any reason that I could see, than just choosing an arbitrary number and making the resulting trade-off arbitrarily.  I think by some argument the interval "doesn't matter" in quite the same way it does when attached directly to subsidy distribution, but I'm also struggling to fully convince myself of this either.  (There's a proof waiting to be written, one way or the other, here.)

Do you have an ETA?

Worst case would be 12 hours or so, and that's assuming my computers all literally catch fire or something of the sort.

Probably more like 4-6 hours to make the change, test, eat some foods, build, find someone to build the windows motogame.exe (any volunteers?), test more, and upload.

Hopefully even less, I'll eat quick foods.

[e1ghtSpace]

Alright, that should be very easy to implement.

Yes, it would basically be just a somewhat "redundant" patch to GetNextWorkRequired, nothing more.  It is, in a sense, a change we just made once, already.

Do you have an ETA?

Worst case would be 12 hours or so, and that's assuming my computers all literally catch fire or something of the sort.

So will this patch slow the bot down a lot so humans are able to mine? And how soon do you expect this to happen? Good work btw.

[Vz]

Average Nonce of blocks close to 200 000 

Fantastic speed of generation maps

[Spiky]

No matter how we dislike these bots I'm absolutely sure we must not set the fork point in the past, only in the future, because this would totally compromise the coin (even if no significant transaction cancels). This bot doesn't violate any rule so we must not take away his coins.

Also, we need to discuss the next anti-bot patch.

I just want to repeat my suggestions (I still think they will work):

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.

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.

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

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.

[HunterMinerCrafter]

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.)

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.

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.

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.

[HunterMinerCrafter]

Hit a few snags, but am nearly done with patches now.

[Spiky]

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.

It's not a problem actually, we can try to find some heavy hash alghorithm which require huge amount of memory (bye-bye asics) and which are very inconvinient for GPUs.

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.

We don't even need to make them unnoticable. Parameters can vary within the range +/- 20%. I bet it wouldn't be a problem for people even if they would need to drive bike and 5 seconds later it would transform to hellicopter.

Anyway, the final decision is yours of course...

[HunterMinerCrafter]

It's not a problem actually, we can try to find some heavy hash alghorithm which require huge amount of memory (bye-bye asics) and which are very inconvinient for GPUs.

This is mostly just another holy war that I'm going to try to avoid stepping into.  All I'll say here is that I don't currently intend to explore replacing SHA, and you'll probably have a tough time convincing me that there would be any sustainable benefit.

We don't even need to make them unnoticable. Parameters can vary within the range +/- 20%. I bet it wouldn't be a problem for people even if they would need to drive bike and 5 seconds later it would transform to hellicopter.

Sure, but if you make them too noticeable it just becomes something else bots can leverage, too.

In any case you have the frame-rate inconsistency problem to resolve.

Anyway, the final decision is yours of course...

Not really, anyone can propose a patch.  (I'd much prefer it if I weren't the only one implementing changes, anyway.)

[MaxDZ8]

It's not a problem actually, we can try to find some heavy hash alghorithm which require huge amount of memory (bye-bye asics) and which are very inconvinient for GPUs.

Inconvenient for something which usually has twice the bandwidth, twice the processing power, can be equipped twice as easily and can reduce latency to one hundredth.

Let me put this in a way everybody can understand: CPU massive processing is dead, it has been dead long time, either you acknowledge the fact or lie about it... and then get your ass kicked big way when the GPU advantage is unlocked.

The anti-GPU stance is a position only ignorants can defend.