[ANN][MOTO] Motocoin

[HunterMinerCrafter]

https://github.com/motocoin-dev/motocoin/commit/37e8df5d1456494f40cd8f1ad5ed74a593928146

Code:

Block 196000 fork
  10 times more frequent (200 block) anti-warp target interval
(also removes map filters)

I'll upload builds shortly.

[Spiky]

OMG. Nobody will update it in time. Make it at least at 200000.

[HunterMinerCrafter]

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.

I imagine that at some point the hashing work portions of Moto will have to have an option to use GPUs.

[HunterMinerCrafter]

OMG. Nobody will update it in time. Make it at least at 200000.

It shouldn't matter much, as long as you upgrade before transacting?

EDIT: How about we split the difference and say 198000? I'd have to restart builds.

[Vz]

Cool! 198000.. just notify C-CEX!  



One question. So the Anti-Warp will increase the needed work to generating one map, until what?

[Spiky]

EDIT: How about we split the difference and say 198000? I'd have to restart builds.

198000 is OK!

[HunterMinerCrafter]

EDIT: How about we split the difference and say 198000? I'd have to restart builds.

198000 is OK!

Will do.

[HunterMinerCrafter]

One question. So the Anti-Warp will increase the needed work to generating one map, until what?

Work requirement increases until there is no longer a warp defecit, meaning solutions do not come in faster than TT.  This means that on average all participants in the network will have at least TT worth of wall clock time to perform the traversal solving step after generating their map.  A "flawless" player using no rewind and playing at realtime framerate would always have an opportunity to solve.  Assuming they always got a good solvable map on the first try, such a player would always end up with a hypothetical 50/50 shot to beat any given bot, before considering map iterations.  Of course map selection is a lottery, hence the relative ratio on nonce iteration factoring into total odds of finding next block, as I outlined in my earlier post.

[HunterMinerCrafter]

Fork point updated to 198000.

https://github.com/motocoin-dev/motocoin/commit/ab5af1425639d0fa3c35c5821fa20a05ae8d5d75

Builds restarted.

[HunterMinerCrafter]

New builds are up.

https://github.com/motocoin-dev/motocoin/releases/tag/HMCtesting2

[tianjinlian]

New builds are up.

https://github.com/motocoin-dev/motocoin/releases/tag/HMCtesting2

nice , thanks for job

[JessicaSe]

New builds are up.

https://github.com/motocoin-dev/motocoin/releases/tag/HMCtesting2

Nice... faster then expected.

[Vz]

NONCE 2 497 787 !!

and only 15 seconds for that ?

6 second and 8 000 nonce
2 300 000 and 12 seconds..


HOW?

[MotoLevi]

I managed to mine 2 blocks now. One seems to be dismissed though . The other one is waiting for confirmations.

[HunterMinerCrafter]

NONCE 2 497 787 !!

and only 15 seconds for that ?

6 second and 8 000 nonce
2 300 000 and 12 seconds..


HOW?

There are a lot of simple explanations.

First, don't assume that they are starting from 0.  If you run multiple machines against the same work data you will certainly start nonce iteration from different values so as not to overlap work.

Second, don't assume that they are iterating at all like the wallet would.  They are probably using some "bail out" opportunity in map filtering to get a few extra iterations in.

Third, they may just actually be iterating at these speeds.  They may be using GPUs or even more specialized hardware for the map filtering.

Without being able to see the nonce selection process we can't really know much about a nonce.

[HunterMinerCrafter]

Graph comparing linearly extrapolated anti-warp work requirement with the old (2000 block) interval and the new (200 block) interval.

The vertical is "our compact representation" target values, so this graph is in something like a "distorted" log scale.  We can't really know where the target will level off until it levels off, on either curve.  However, we can say that this will get us to whatever that target value is significantly more quickly.  If it still feels that we are targeting too slowly for the bot (or for the ongoing bot progression, in the future) we can increase this frequency again.

It probably should eventually be at a much lower value, with our tx confirmations increased.   Ideally, I think we'd want to have this anti-warp set at something like 10-20% of our desired confirmations, with something like 60 confirmations at one minute frequency.

[Vz]

Fantastic! I just win 20 MOTOCOIN  and it is confirmed)

[zeerobje]

Hello all are their new things come in the next months....

[Vz]

Hello all are their new things come in the next months....

oO.. which things? HMC already finished new builds you may download by links upper post..

So we just need to wait until the time-warp normalize the currect situation

[HunterMinerCrafter]

Fantastic! I just win 20 MOTOCOIN  and it is confirmed)

Bot is offline now?  Interesting.