Topic: [ANN][MOTO] Motocoin - page 57. (Read 178225 times)

***** Cancelled because I think I might be able to work it out*****
I will give you 0.005 BTC to the first person that compiles the bot for windows (x64) and upload it somewhere for everyone.

The BTC will go to the first person who posts the download link.
***** Cancelled because I think I might be able to work it out*****

Seems that difficulty readjustment can't handle it.
Blocks 52k-54k were mined in 58145 seconds.
Blocks 54k-56k were mined in 56334 seconds.
Blocks 56k-58k were mined in 60556 seconds.
Blocks 58k-60k were mined in 53245 seconds.
Blocks 60k-62k will be mined in 52360 seconds (estimated).
While target is 2000 blocks in 120000 seconds.

Just synced and looked again:

I think easiest solution (for now, eventually bots will learn) is

Increase map Size (needs to be wider) - as hcm said.
Remove mirror image, so is just square.
Start in top left, and coin in bottom right.
Add walls to left and right sides.

The problem is the free fall, the angle is not large enough (edit : slight enough?)

First i thought the maps are being generated looking for direct paths..
now i realized they are being generated maybe based on the freefall... and is solving them at the same time as looking for them.. i.e. it's not finding the map first by checking paths then playing the map many times (brute force) (as i previously thought).. it's finding the map+solving at the same time..

probably it still need to do a few tries .. maybe it generates/simulates a free fall MAP at the same time, but removes "death component".. if it doesn't reach the coin on the freefall, it tries another map, until it finds it..
.. when it lands on the coin, it uses this map as a base, and brute forces this with death component enabled - but is very simple as only need some rotates

i've not checked out the released bot, so maybe someone else's could be doing that if released one isn't :d

If the angle is greater than a free fall, the bots will need to take in more variables, like accelerating / jumping

maybe this will make it much more difficult for humans also.

probably it can still find a map which is doable (1 big long slant), but i think 1000x harder.

maybe just the map needs to be a lot wider than taller,


Could be wrong.. is 530am and drunk

sober edit: -- maybe still need some perma obstacles to prevent a long slant.. (or flat drive along top, then a freefall)
just example (not a good one) - probably this is not possible to played by humans


although - it could freefall to the left, then have a straight flat drive near the bottom (but then the angle will be very slight) - for now maybe just need to do the above without obstacles? --- what would be best is if some bot master who already now has a massive amount of coins tried his bot with some sceneraos which are least effective. - but that's not how the world works unfortunately

I am just pushed small update, now it is less network intensive. It is still not perfect, but I think that little aggressive behavior is ok for miner, since it is not basic network node.

Interestingly it seems that, for the moment at least, everyone who is checking out your bot is now all synced up!  The spammy getblocks have subsided, with the exception of a couple of nodes that keep doing getblocks from block -1, which I'm guessing is an effect of some sync bug in the reference code, or something.

Check out Huntercoin, then!  At the moment, it is the closest there is.

I think he meant to say that soon it will be "human mine-able" again.  It is still proof-of-play right now, as it stands, but it is not currently human mine-able, at least not in practice.  The two concepts are not entirely the same thing.

On any currency network the proofs must be machine verifiable, which in turn implies that the proofs must be "bot-able" since they will always be able to be brute forced (if nothing else) with some degree of success.  (You can never have a network on which bots cannot ever operate at all without that network being inherently insecure.)

With the additional difficulty change block intervals will be constrained to the frequency established by TT.  This means that bots (and humans, alike) will not be able to produce blocks faster than TT, on average.  Not only will this recover human mining, but it will do so in a way that any significant advance in bot mining technology in the future couldn't realistically "leapfrog the humans" by a faster block submission frequency again.  The bots (and humans alike) will be forced to actually compete on TT instead of block latency, and to do so at the same average relative frame-rate as everyone else.

(EDIT: P.S.  5USD seems optimistic.  Eventual USD parity, however, would not surprise me much.)

It is inevitable, basically.  You can never make a game that can not be played by bots, you can only ever hope to make a game that is sufficiently difficult that bots cannot drastically outperform.


It is still play, it is just a sort of meta-game.


This is related to the difficulty time warp attack.  The attack is basically only possible because you (where you is either a human or bot miner) can actually be well above 100% efficient, in a sense.  Players in the reference client have some ability to warp in-game time, but the network itself allows in-game time to be warped relative to wall clock time much much more than it should.


The problem is that there is no systematic way to draw the line that doesn't lead to a lot of human players being falsely flagged.  Why should I want to improve as a skilled player if I know that at some level of mastery I'll be cut off from my reward for being "too successful."  Who wants to play a game where they lose for winning?


We should not want to centralize the network in any way.  If the devs "get to know" they also get to just tune their bots to be the only productive bots on the network (since they hold the secret magic numbers to tune against) and dominate the mining process.  This would certainly be no good for what are, hopefully, self evident reasons.


You can't formally define "inhuman efficiency" for the network to measure against.  If you can't formally define/codify it, you can't really have the network establish proof based upon it.  This holds for any kind of "proof of whatever" system.  (In other words, something like "proof of swag" can never really work, because machines can't independently verify a precise measure of swag.  Even a skilled professional swag assessor probably couldn't reasonably define "too much swag to be human generated swag.")  Because of this, we have to keep to a seemingly peculiar, but actually quite sensible, definition of "play" in order for things to work out.


I'd start by reading and re-reading (over and over again until it all seems "obvious") the satoshi whitepaper and the protocol notes on the wiki.


I'm sure there will be easier miner setups and mining pools before long.  I hope to eventually launch an easy-to-use pool which will offer some basic bot algorithms.  In the meantime, minim1ner's bot is not hard to use if you already have linux boxes handy.

Too hard, I would prefer if there is MMORPG coin game

Even if this will happen in a couple of days it may again become proof-of-bot.

Better hurry. Soon this coin is prove-of-play again and the price rises back up to 5 USD per coin.  

https://c-cex.com/?p=moto-btc

Don't like to dig.How to get?Where to buy?

I got busy this week and simply haven't had the time to finish verification on the patch.  By this weekend we can launch a testnet with it, and if we are all happy with the change we can initiate the fork when we're ready.


Ahh, that sounds a bit more reasonable.  I thought you meant you were getting those rates from a single ~2ghz core, which would be quite a bit better than I would expect.  At 4 cores these numbers are very much in line with what I'd expect.


Heh, the problem is I'm a well connected node and have multiple people syncing from me at any given moment.  From people using your patch i see a getblocks request for, say, block 10,000... so I send them 500 blocks, and they turn around and 10 seconds later issue a getblocks request from block 10,050 or so, so i send them the same 450 blocks again with 50 new blocks.... rinse, repeat.  This creates a lot of overheads!

Yes, it just was quiet for a while, I thought development is stuck, or William rejected pull request or something.

No, I use all 4 cores @1.6 ghz.

It will spam just to 3 connections, not to 10 or whatever.

I'm not sure how those parameters would affect anything...  also keep in mind that I'm running without your patch, it is the other nodes (that are running the patch) on the network making this chatter while they sync!


On what spec cpu?  That is a pretty good production rate if it is just one core!

My patch to fix the time warp will already do this as a side effect. (Remember from our pm?)

I'd better make a patch that prevents map brutforce, if devs agree with this idea, I could do it. With this patch map generation will take little more time, but it will be the first step to destroy bots.

I'll take a look at it later. For now run it with parameters.

I am getting ~10 blocks per hour with this bot. Can't tell anything about crashes, it seems pretty strange.

Now it's working, looks like that were some issues with my scripts & vds memory limit.

That feeling when you realize that you changed the wrong source file and have been mining an invalid chain on your live bots, instead of testnet, for over 12 hours....