Topic: [ANN][MOTO] Motocoin - page 36. (Read 178256 times)

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.

Average Nonce of blocks close to 200 000 

Fantastic speed of generation maps

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.

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


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.

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

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.

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.

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.

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

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

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.


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.


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

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.

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?

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.

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.

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?

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


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

I wanted to join, but BOT always destroy cool idea ;/ sad but true ;/

Looking good!

Isn't everyone "the server". I knew there wasn't a central server.