[ANN][MOTO] Motocoin

[HunterMinerCrafter]

• I already wrote it above, and still believe it is true:  Such problems, where the "actual goal" is to give cutting-edge research an order-of-magnitude advantage, is not suited to securing a network of transactions.  I wouldn't want to run an exchange and accept a currency that could be 51%-attacked every time someone made a break-through.

This is kind of the difficulty-time-warp problem in a nutshell.  This is why I'm thinking that the work function needs to also include a scale of computational complexity in addition to the challenge target.  We should have two difficulties, one to throttle block production in general, computational complexity, and one to scale the difficulty of the challenge, maybe we could call this "cognitive complexity."

 (HunterMinerCrafter stated himself above that he could 99% Motocoin if he wanted to.  While trusting him not to do it is possible, I wouldn't want to have lots of money at stake with that.  Then I could just put it into the bank, after all.)  Having the currency "just for fun" and not intended/advertised as fully secure (as Motocoin's website still does) makes this point moot.

There was a time when btc had only a small handful of miners as well, any one of whom could have 99%ed bitcoin then, too.  Every coin goes through such a phase.  The beauty of a blockchain is that you don't necessarily have to just trust me implicitly, instead you could just fire up your own bot rigs and dilute my hash rate.  (The difficulty-time-warp attack vector aside, anyway...)  As more and more participants choose not to blindly trust each other the network eventually becomes strong enough that no one has to.

• While I'm all for promoting research (I'm on a research grant myself, although not related to AI or crypto-currencies but applied mathematics), I also think that results should benefit the community at large (keyword "Open Access publications", for instance).  I doubt that the research done for bots on Motocoin or a similar currency would at all be published somehow, as it is in the botters' best interests to keep their results in secret.  Why should the community of currency investors pay them for something they research just for their own profit?

They probably wouldn't, directly... at least not while they are still "cutting edge" in terms of coin production efficiency.  However I'm sure that once the naive bots are no longer productive they would be released for study, once there's no longer direct incentive to "keep the secrets."

Also advances in algorithms and infrastructure that arise out of work on moto bots could easily find their way into other systems/products, and benefit everyone indirectly.

[HunterMinerCrafter]

Blockchain fork frequency is a little increased lately, and at a glance it doesn't look like the usual "stales between miniminer and I" type forking.  Is anyone set up to do a quick double-spend analysis?  If not I'll put together the relevant patches later today.

As a precaution, I will be increasing my hashrate.

Also, TT=16.872 now.  Only 8436 frames to get to your coin.  Good luck.

(Bots are solving mostly within about 2k to 4k frames now, so expect TT to continue downward.  Whoever said the uncontrolled block submission frequency would mean no competition would occur on TT was apparently incorrect!)

[snailbrain]

apologies i've not read through all the recent posts - assuming i'd understand it

it seems to me that all the maps being completed can be done  by humans just as fast

the problem maybe is just the generation of the maps
all the recent completed maps look like this:



the bots don't need to be that "good" (assuming they are bots) - they just need someway of finding easy paths by generating millions of maps - probably someone could just generate the maps the same way and then play it as a human (assuming this isn't what's happening now)

maybe if each map has some permenant blockage to prevent it being just a "freefall"

very crude image example - and would need to be thought about more



this way, any bots need to move / change directions - probably/maybe making it more complicated, so they can't just fall to the coin  (they will still do it eventually) - and maybe the blockages would need to move slightly randomly based on blockhash (so doesn't change when F6), but atm i think they aren't as smart as people think (from looking at the replays).

wouldn't be a permanent solution mind you

note: I could be wrong and the bots have it down to perfection - and the generation of the maps in this way is just an extra bump for completing it quicker

[HunterMinerCrafter]

apologies i've not read through all the recent posts - assuming i'd understand it

Hello old friend!  I'm very pleased to see you jump into the conversation.  I have every indication, now, that the MOTO developers have simply given up, so it is good to see some other smart, respected folks like yourself joining in!  With enough of us still caring we *CAN* save this coin.

it seems to me that all the maps being completed can be done  by humans just as fast

the problem maybe is just the generation of the maps
all the recent completed maps look like this:

Yes, the current iteration of bots are very simple/naive, not even as smart as the most basic of huc bots.

Humans can certainly solve these maps within the target time, the problem is that until the difficulty retarget and "difficulty time warp" problems are addressed, the humans don't even "get to try" because even if they were given the same "easy maps" that the bots select for themselves the human simply can't press the keys fast enough to solve before a bot does, and their map resets.

the bots don't need to be that "good" (assuming they are bots) - they just need someway of finding easy paths by generating millions of maps - probably someone could just generate the maps the same way and then play it as a human (assuming this isn't what's happening now)

I might be able to be convinced to release a client patch which would generate and select a map for a human using the same or similar heuristics as what the bots use to select them.  This would increase humans' margin a bit, but I suspect that the block frequency, and subsequently the map reset frequency, would still overwhelm the humans.

maybe if each map has some permenant blockage to prevent it being just a "freefall"

very crude image example - and would need to be thought about more

this way, any bots need to move / change directions - probably/maybe making it more complicated, so they can't just fall to the coin  (they will still do it eventually) - and maybe the blockages would need to move slightly randomly based on blockhash (so doesn't change when F6), but atm i think they aren't as smart as people think (from looking at the replays).

wouldn't be a permanent solution mind you

I put this in the same category as simply increasing the map size; something that would hinder the current naive bots, but would have little or no impact on the upcoming wave of "smart" bots.

note: I could be wrong and the bots have it down to perfection - and the generation of the maps in this way is just an extra bump for completing it quicker

You are not wrong, but it is just a stop gap solution.

In any case, this is still a bit "cart before horse" since the most critical problem right now is not really the bots' dominance, but the potential for someone to use their bots to (massively) fork the network with a (possibly difficulty time-warp based) 51% attack.

[DeepCryptoanalist3]

it seems to me that all the maps being completed can be done  by humans just as fast

I thought that some of current "bot owner" guys aren't even a bot owners. They have just made this easy map preselection cheat and riding that simple levels by hand. But then time between blocks have tightened to the target time. I am not sure about this now. A good prove that bots are actually exists can be the fact that time between blocks became significantly smaller than the target time. Is this the case now?

Anyway if the coin have been hacked in such a way then it should be abandoned. New version of the coin should have new genesis block. Those who play on this easy maps are went against the rules and they shall not receive the reward for this. If it will not be abandoned then it will be an indisputable sign that some of those cheaters are the coin developers themselves.

[BTCat]

How about a very simple captia before every map starts to prove you're not a bot. There must be other ways to make it hard for bots and easier for humans.

[HunterMinerCrafter]

it seems to me that all the maps being completed can be done  by humans just as fast

I thought that some of current "bot owner" guys aren't even a bot owners. They have just made this easy map preselection cheat and riding that simple levels by hand.

I think this is unlikely or, at least, didn't last long at all.  Possibly (likely?) some of the bot developers started with this approach (I didn't, personally) but if they did such a patch they would've quickly realized that even a trivial automation of "the rest of the work function" would significantly outproduce.

Also, I'm not sure I would even call this "cheating."  The only way that we have to define cheating is the protocol itself, and the protocol itself is decided by consensus of miners.  This behavior would be entirely "within protocol" so as such this would not fall under the current definition of cheating. (until a patch is adopted, and the majority hashing strength has, so far, agreed that they would accept such a patch.)

But then time between blocks have tightened to the target time. I am not sure about this now. A good prove that bots are actually exists can be the fact that time between blocks became significantly smaller than the target time. Is this the case now?

Mostly.  I don't think the very existence of bots is at all in question, some of the block intervals are clearly not humanly possible.

Anyway if the coin have been hacked in such a way then it should be abandoned. New version of the coin should have new genesis block. Those who play on this easy maps are went against the rules and they shall not receive the reward for this. If it will not be abandoned then it will be an indisputable sign that some of those cheaters are the coin developers themselves.

I'm all for changing that definition of "cheating" moving forward, however I don't think a hard fork back to block 1 would be appropriate.  That, IMO, would be antithetical to the very nature of a block chain consensus.  Why even have block chain consensus, then?  (Just make the moto game itself hosted on a single central server at the main dev's house, while we're at it!)

[HunterMinerCrafter]

How about a very simple captia before every map starts to prove you're not a bot. There must be other ways to make it hard for bots and easier for humans.

Captcha can't work.  We covered this quite some pages back.

[psychocoin]

Since the dev doesn't seem interested in furthering the goals of the coin and its community anymore...

HMC: Do you have any proposal for a fork, or did I misunderstand and you are not actually interested in committing solutions and code yourself?

Would the best course be to continue the current blockchain or to relaunch? We would at the very least need to start a new thread to discuss post-original-developer proposals, aye?

Perhaps the dev wouldn't mind transferring the ownership of the github, official website/domain and such things to a new lead dev if they are indeed done with it? Or am I jumping ahead of events here?

[HunterMinerCrafter]

Since the dev doesn't seem interested in furthering the goals of the coin and its community anymore...

HMC: Do you have any proposal for a fork, or did I misunderstand and you are not actually interested in committing solutions and code yourself?

I would certainly be willing to work on appropriate patches.  However, I am not yet anywhere near having such a patch ready.

Although I've done some small experiments with different options, I don't yet have a solid solution (for the difficulty time warp problem) implemented.

As I see it we have four viable options to controlling block frequency:

 * Constrain block frequency by timestamp, as proposed by DeepCryptoAnalyst.  Pros are simplicity and ease of implementation.  Cons are that it weakens the timestamp reliability (as miners then have incentive to use timestamps as far forward as possible) and increases incentive to timejack (as nodes have incentive to lie about their clock) which may cause problems as rational miners try to maximize profit.

 * Introduce forced computational complexity scale into map generation, likely by simply requiring many rounds of hashing.  Pros are ease of implementation and a side effect of hampering (current generation) bots.  Cons are the possibility that map generation could quickly become sufficiently difficult that human players without specialized hardware could be unlikely to be able to generate a map in reasonable time, and might never be able to begin playing a map.  (This could be mitigated some by my "N heads" proposal, though.)

 * Introduce forced computational complexity scale into frame calculation itself.  This could be done by several mechanisms.  Pros are a maximum of network security in all cases, and a side effect of hampering (current generation) bots.  Cons are complexity and difficulty of correct implementation, and the possibility for an impact on framerate.  (Eventually, difficulty could become high enough that human players without specialized hardware would suffer reduced framerates.)  

* "Punt" and move to a classic hash-collision based chain with motogame coinbases being generated in something of a transaction overlay, in the style of Huntercoin.  Pros are a maximum of network security in all cases, the fact that we already know that it can work well as it is not a new approach, and the ability to allow merged mining with other chains.  Cons are that the coin would become no longer only mined through the single motogame work function.

Does anyone see a fifth option?

Would the best course be to continue the current blockchain or to relaunch?

I don't see any good rationale for a relaunch, and historically relaunches have been devastating for alt-coins.  The chain appears to have remained secure, despite the potential for abuse, because miners have acted in the best interests of both the coin and their own financial gain.  This is akin to calling for Bitcoin to totally relaunch because ghash has 51% now.  (I think anyone who proposed this for btc might just be laughed out of the room.)

We would at the very least need to start a new thread to discuss post-original-developer proposals, aye?

Yes, and we may even want to go so far as to re-brand the coin some.

Perhaps the dev wouldn't mind transferring the ownership of the github, official website/domain and such things to a new lead dev if they are indeed done with it? Or am I jumping ahead of events here?

This would be ideal but, since we still don't even have a response from the devs about the situation, it might be a bit soon to be considering.

If they explicitly do not want to either continue development or give up control of the repository than we will be facing a somewhat tricky situation in handling our hard fork, and will almost certainly want to consider "re-branding" to distinguish our patched client from the original.

[HunterMinerCrafter]

TT 15.992, competition still heating up!

It will be interesting to see at what target time the naive bots begin to struggle, allowing more time for humans to solve again.  So far there is little sign of them slowing.

[Vz]

TT 15.992, competition still heating up!

It seems to me that botowners now deliberately slowed down bots on tpe frontier 32000, maybe to slow down TT drop down?

[Vz]

So the TT have increased.

[btler420]

Won 4 games but no coins 

[WilliamLie2]

I am definitely not going to fight bots. It seems that all of the proposed solutions can only prevent bots for some time, it may be necessary to perform hardforks every few days/weeks to adapt to new bots. The only thing that I want to fix is this vulnerability, "difficulty time warp" as HMC calls it.

I don't see how a bot owner (HunterMinerCrafter) can continue development to make it more human-friendly and constrain bots. As a bot developer he can improve his bots beforehand before releasing anti-bot patches, this is definitely a conflict of interest which will negatively affect community trust in Motocoin.

Instead of fighting bots I think that current bots should be released into open source so that everyone can mine again.

P.S. It seems that someone turned off his bot (maybe it was miniminer), blocks are now mined much slower than before.

[HunterMinerCrafter]

I am definitely not going to fight bots. It seems that all of the proposed solutions can only prevent bots for some time, it may be necessary to perform hardforks every few days/weeks to adapt to new bots. The only thing that I want to fix is this vulnerability, "difficulty time warp" as HMC calls it.

Yes, the "fighting" the bots would be problematic.  Asymmetric warfare problem, basically.  The goal should always be balance for both bots and humans.  We must coexist.

In any case, the difficulty time warp should certainly be the focus.  You still have not really said if and how you plan to address that.

I don't see how a bot owner (HunterMinerCrafter) can continue development to make it more human-friendly and constrain bots. As a bot developer he can improve his bots beforehand before releasing anti-bot patches, this is definitely a conflict of interest which will negatively affect community trust in Motocoin.

There is not really any conflict of interest here.  It is in my best interest to have humans able to remain competitive in the long run, otherwise the coin offers no value over any other random alt coin.

Instead of fighting bots I think that current bots should be released into open source so that everyone can mine again.

Yes, as I've said the best thing for the network right now would be an increase of bot operators, to decentralize the security of the network.

P.S. It seems that someone turned off his bot (maybe it was miniminer), blocks are now mined much slower than before.

Possibly, but I'm not sure why they would at this juncture.

[WilliamLie2]

I think that it's better to solve difficulty time warp problem in the most obvious and simple way, that is to change the way required work is computed. Currently it is computed as 1/t, that is 15 sec target time is considdered to be 4x more difficult (takes 4x more time) to find solution than 60 sec and this is probably not the case. You (and other bot operators) can do some experiments to determine how required time to find solution depends on target time, then we can construct some function that is good approximation of this dependency and use it instead of 1/t.
Another counter-measure is to add checkpoint, it will prevent whole chain forking.

[HunterMinerCrafter]

I think that it's better to solve difficulty time warp problem in the most obvious and simple way, that is to change the way required work is computed. Currently it is computed as 1/t, that is 15 sec target time is considdered to be 4x more difficult (takes 4x more time) to find solution than 60 sec and this is probably not the case.

I think Domob already pointed to the fatal flaw in this sort of approach, and DeepCrypto already pointed to the solution.

The problem is that at any time someone could come in with something that massively makes an epic leapfrog in performance, and (at best) just put us back into "block latency race" mode.  I'm not talking cpu->gpu->fpga->asic type progression, but a total smashing of the big O computational complexity of a solver.

I think DeepCrypto would agree that any meaningful solution will/must involve calculating difficulty (or difficulties) by some measure of both target time and block acceptance frequency, somehow, and must scale both.

You (and other bot operators) can do some experiments to determine how required time to find solution depends on target time,

I might try to put together some numbers, but this might ultimately be harder than it sounds to do accurately, from what I've seen so far.  

then we can construct some function that is good approximation of this dependency and use it instead of 1/t.

I think we need to do this from the start.  This also relates to why the direct association between control of block frequency and target time is necessary to actually call the attack vector closed.

Another counter-measure is to add checkpoint, it will prevent whole chain forking.

Agreed!

[DeepCryptoanalist3]

I think that it's better to solve difficulty time warp problem in the most obvious and simple way, that is to change the way required work is computed. Currently it is computed as 1/t, that is 15 sec target time is considered to be 4x more difficult (takes 4x more time) to find solution than 60 sec and this is probably not the case. You (and other bot operators) can do some experiments to determine how required time to find solution depends on target time, then we can construct some function that is good approximation of this dependency and use it instead of 1/t.
Another counter-measure is to add checkpoint, it will prevent whole chain forking.

The map shall be enlarged anyway. The current state is ridiculous. Bots or humans they do not play the game but only falling through simple maps. That completely ruined the idea of a mining by play idea. Current state is not stimulating any AI research either.

I think DeepCrypto would agree that any meaningful solution will/must involve calculating difficulty (or difficulties) by some measure of both target time and block acceptance frequency, somehow, and must scale both.

Calculation difficulty shall prevent map preselection cheat. I am not sure that any other difficulty measure would be needed if map will be big enough to force competitors to actually play the game.

And yes. Time warp bug shall be closed somehow anyway. Time warp attack is not very relevant to anti bot measures.

[HunterMinerCrafter]

I think DeepCrypto would agree that any meaningful solution will/must involve calculating difficulty (or difficulties) by some measure of both target time and block acceptance frequency, somehow, and must scale both.

Calculation difficulty shall prevent map preselection cheat. I am not sure that any other difficulty measure would be needed if map will be big enough to force competitors to actually play the game.

And yes. Time warp bug shall be closed somehow anyway. Time warp attack is not very relevant to anti bot measures.

I meant as a solution to the time warp bug.  Basically, I think we can say that block acceptance frequency needs to be constrained/controlled directly by the network via the work function's complexity (not indirectly by how people(/bots) are assumed to play) and until it is it still potentially leaves the attack vector open.  With any solution that only constrains based on target time any new improvement in machine mining that better calculates bad (high TT) solutions could rewrite back to the last checkpoint with a longer, lower difficulty chain.  In other words, if we are only ever constrained by target time then anyone who could just find a way to run the naive bots much much faster could dominate production and/or "51% attack" by difficulty-time-warping the chain, and "should" just not bother with any AI.  This would be an undesirable outcome for everyone.