Topic: [ANN][MOTO] Motocoin - page 60. (Read 178259 times)

Yes, I'm not working on anything now but I will look at your patches when they are ready. And what's wrong with my implementation of tt calculation?

It is for bots.

I play video games really nice!  I am proffesional gamer. That is a coin for me.

Would it be possible to perhaps have a choice among several games to play to mine? Playing any one of them could win you the block and difficulty would be adjusted on each one of them individually, to ensure that overall/relative difficulty is roughly equal and mining takes equal amount of time on all games. And if players/botters are sticking to one game too much, that one would also be made more difficult (or others made easier) to ensure all games get played.

Now, all we need is to come up with a bunch of fun skill-based games where rounds/maps can be completed in minutes or less and where humans could at least for an extended period of time reasonably compete against AI miners, with every reasonable effort taken to prolong such a period. And past that - it should still be a fun process to come up with AI solutions and watch your bots at work.

A reasonable feature could be an in-built scripting engine into the games and perhaps even a very, very simple and inefficient bot written in it as an example, to encourage others to come up with smarter, more efficient bot logic on their own.

Come on, someone make this happen

So far the official developers still haven't said much, except for "no eta" basically.  We have every indication that they do not yet have any patch code.

I am working on a series of patches to propose.  The first two are to fix various problems with difficulty targets.  One closes the difficulty time warp attack by establishing a difficulty target for hashing rounds during map generation.  The other fixes the TargetTime calculation itself, to better match what is described in the whitepaper.  (Right now it is downright incorrect.  Basically it is not actually using a median of the lookback period.)  We will likely still want to change/replace the target time calculation at some point.


My patch would calculate the correct TargetTime at the hard fork, and go from there.  I am not sure offhand what TT that would be on the real chain.


I will not be making a patch to change the map size.  For a lot of reasons I decided against implementing it.  If someone else proposes a good patch for it I will adopt it as a miner.


The problems to be solved first are very difficult.  Although I feel that I have a good notion for the couple of solutions that I intend to offer up, I'm not confident that I've done enough testing of them yet.


I'm not entirely sure what you're asking.  You could fork the coin into a new coin on a new chain, with the same game as the work function.  It is not hard to do "testnet in a box" with most anycoin.


It would be interesting to replace the work function with a new game, in my opinion.  We need better coins 3.0 not just lots of competing replica like 2.0 were. 

I hope the patch comes out soon. Also, will the block time start back at 60 seconds? This is going to be interesting with differently sized maps.
Any ETA for the new version?

Another question:
Is it possible to fork this coin with the game still working? Or does the game break?
Because someone should fork the new version and call it play coin.
Actually i'm going to try to do it when the new version comes out. It'll be fun. (unless the game won't work)

Wow this has sparked my interest.. which is odd for an Alt besides the bit ones...
Gonna download her and give it a whirl
I quite like the concept.

Just got into the office bright and early to discover that MOTO is on the move.  I guess we spoke too soon!  A new high price since the crash was set, volume is #3 on ccex for today, and it looks like the rest of the resistance wall is being nibbled at.

This is shaping up to look like it is probably what I'd call "smart, early money accumulating!"

But there is liquidity!  I think everyone is in "wait and see" mode.


Sort of.  A whole $2USD was traded at $0.02994/moto today! 


Yah, pretty quiet right now...


Yes.  I might even turn one or two into pull requests.

Pretty interesting

Market volume is nonexistent (although price seems to be pretty stable around 1000 Satoshis for the past 2 weeks) and discussion seems to have died off. Not a nice sight.

Are any patches being worked on at the moment?

TT seems to be converging on this 16 second point, maybe?

How about we scale the both the map dimensions and rounds of hashing to generate seed?  This should make it pretty easy to get a nice 2^n curve, and as a nice bonus hits the bots with a bit of a "double whammy" on performance.  From some guesstimates, I think that the additional hashing rounds would not impact humans for a very very long time when many many hashing rounds would be required.  Scaling the map dimensions as well might cause the motoF function used map rendering to take a performance hit.  (I don't recall offhand if the rendering does this once off and caches the texture, or if it recalculates each frame.  In any case it should probably pre-cache unless we intend the terrain to be dynamic in the future.)

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.

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.


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


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.  


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.


Agreed!

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.

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.


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.


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.


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