[ANN][MOTO] Motocoin

[WilliamLie2]

EDIT: The more I think about this idea of the bias the more scary it becomes.  It not only just restates the difficulty time warp problem as a difficulty+timestamp time warp problem, but actually gives your average miner motivation to timejack attack his peers without even caring to attempt double spend, just to bias their notion of the current time and increase the odds that a "far out" block will accept.  Difficulty adjustment becomes unreliable and volatile. A whole new family of attack vectors get created.  It is all around scary stuff.

What do you mean by bias?

I mean limiting the amount in the future that blocks would be accepted relative to the amount in the past.  These should remain even.

I'm now much preferring the idea of simply returning to a more classic adjustment, allowing difficulty to potentially go "too far" and including an upward pressure on targettime to bring the chain back into a mineable state should the difficulty exceed the possible traversal time of any possible map generation.  Such an approach seems both very safe and very simple now, by comparison!

Can you be more specific? Your description is too vague for me. How is this different from increasing target time depending on global time that we discussed above?

It isn't really... my concern has only ever really been with the bias and the agreement on current time.  We should not bias (because it is problematic) and we can not use current global time for limiting block acceptance (as it is "virtually undefined") but we can still agree on historical global time for retarget, as in bitcoin, right?

I still don't get it. There are 2 cases:
1. No bias. We accept new blocks that are -30 min or +30 min relative to our time.
2. Bias. We accept new blocks that are -2 hours or +30 min relative to our time.
That's what you mean by bias, right?
But what is the difference between these 2 cases? In both cases miners try to set time as far in the future as they can with all the issues that you and me have just described.

[TheXpert]

Probably you need to describe your proposal in more details. I have no idea what do you mean by "target distance".

No need to increase map size, just path to ride.
When you generate the map you know the distance between the biker and the coin
Also you can count minimum distance for biker to reach the coin.
The ratio between these two distances can be used to manage difficulty.


If the ratio is less than needed you just generate new level. Also you can generate only levels that are theoretically solvable, I mean regenerate levels where the coin is surrounded by barriers

Easy lucky levels are easier to solve with bots and easy to generate (using ratio described)
With target distance there will be far more diffucult for bots to solve the level (I beleive) and player skills will be more valuable

Also why not emission curve like bitcoin has?

I really like your coin concept and want this coin to be successful.

[HunterMinerCrafter]

I still don't get it. There are 2 cases:
1. No bias. We accept new blocks that are -30 min or +30 min relative to our time.
2. Bias. We accept new blocks that are -2 hours or +30 min relative to our time.
That's what you mean by bias, right?
But what is the difference between these 2 cases? In both cases miners try to set time as far in the future as they can with all the issues that you and me have just described.

The difference is, in a nutshell, that in the second case I can "go back" up to 2 hours in order to rework my history to form a longer chain that lands within +30min, and in the first case I can only "go back" 30 minutes.  Right there it should be easy to objectively say that case 2 is inherently less secure.

Also, for one more specific example, in either case we likely get the "oscillation" effect that DeepCrypto brought up, but in the case #2 there is the incentive to "game" this oscillation where in case #1 the oscillation is always "counterbalanced."  (Again this is slightly less of a concern because the distribution is not finite but is still a concern, particularly in the "short term" while we are still in the diminishing distribution phase.)

[HunterMinerCrafter]

Probably you need to describe your proposal in more details. I have no idea what do you mean by "target distance".
If the ratio is less than needed you just generate new level.

No need to increase map size, just path to ride.
When you generate the map you know the distance between the biker and the coin
Also you can count minimum distance for biker to reach the coin.
The ratio between these two distances can be used to manage difficulty.

Ahh, this is tricky because mere existence of a particular distance path to the coin does not necessarily mean that the rider can traverse that path under the constraints of the physics.  (Knowing that they could would mean you already have the block solution.)  This creates a second situation under which difficulty could pass the threshold of unsolvable, as well.

Also you can generate only levels that are theoretically solvable, I mean regenerate levels where the coin is surrounded by barriers

This should be added to the reference client in any case!

Easy lucky levels are easier to solve with bots and easy to generate (using ratio described)
With target distance there will be far more diffucult for bots to solve the level (I beleive) and player skills will be more valuable

Not really.  This, too, is really not much different from just increasing the size of the maps.  It will hamper the general "broad search" based bots currently in use, but will do little/nothing to hinder more specialized solutions

Also why not emission curve like bitcoin has?

Do you mean why is there not a finite supply?  This is potentially a (minor?) concern, particularly for speculators.  The intent is that there should never be a case where a user has to either accept a 0 coin block reward, or wait some time to start playing the game.

I really like your coin concept and want this coin to be successful.

If this coin does survive these growing pains I believe it could be huge.  It will certainly open some peoples' eyes to the inevitable future of blockchains, in any case! 

[gogomymoto]

I have updated moto-explorer(yeah, i still belive in moto).

Page with address is more usable now. Added new page with richest addresses: http://moto-explorer.fvds.ru/addresses_richest.php

If you like it, send me a few motocoins here: MoaSd7n8jRSG8JNJVkRdvjDVSgBFpoKGRX9

[DeepCryptoanalist3]

New blocks will be mined at the edge of the accepted time, this will lead to many orphan blocks and network forks (probably short). Maybe more problems will arise, comparison with Bitcoin isn't applicable because in Bitcoin there is no reason for miners to set time to higher values and they just set it to current time and whole network accepts their blocks.

Blocks at the edge of accepted time will not be used by miners as base. Miners will be interested to mine starting from fastest blocks to be able to put their blocks in longer chain. Mining on already short chain pointing to the future is not practical. The same is with bitcoin now. The only real winning strategy is to use blocks who pointing to a moment in time which is closest to the genesis block among chains of the same length.

But the idea of a map enlargement looks also very interesting. This is very easy to implement right now and no need in such a deep analysis and looking for a pitfall. The map is not included into block and will not enlarge it. The size of a map will not affect emulation speed because collision detector needs to check only few closest blocks on every frame. And this solution will automatically kick off any map preselection cheaters. This is a very smooth way to go. Really. Lets remove the time threshold and let the map size be a subject for retarget.

[Jacqul]

New blocks will be mined at the edge of the accepted time, this will lead to many orphan blocks and network forks (probably short). Maybe more problems will arise, comparison with Bitcoin isn't applicable because in Bitcoin there is no reason for miners to set time to higher values and they just set it to current time and whole network accepts their blocks.

Blocks at the edge of accepted time will not be used by miners as base. Miners will be interested to mine starting from fastest blocks to be able to put their blocks in longer chain. Mining on already short chain pointing to the future is not practical. The same is with bitcoin now. The only real winning strategy is to use blocks who pointing to a moment in time which is closest to the genesis block among chains of the same length.

But the idea of a map enlargement looks also very interesting. This is very easy to implement right now and no need in such a deep analysis and looking for a pitfall. The map is not included into block and will not enlarge it. The size of a map will not affect emulation speed because collision detector needs to check only few closest blocks on every frame. And this solution will automatically kick off any map preselection cheaters. This is a very smooth way to go. Really. Lets remove the time threshold and let the map size be a subject for retarget.

I would be keen to see an experiment with this.

[e1ghtSpace]

I have updated moto-explorer(yeah, i still belive in moto).

Page with address is more usable now. Added new page with richest addresses: http://moto-explorer.fvds.ru/addresses_richest.php

If you like it, send me a few motocoins here: MoaSd7n8jRSG8JNJVkRdvjDVSgBFpoKGRX9

Well at least on of the devs hasn't dumped.

[bittick]

where the hell would I find a bot for this? Its unplayable.

[e1ghtSpace]

where the hell would I find a bot for this? Its unplayable.

If you offer a price I'm sure someone will sell one to you.

[HunterMinerCrafter]

where the hell would I find a bot for this? Its unplayable.

If you offer a price I'm sure someone will sell one to you.

Although I've received several inquiries, no-one made any offers.  It would be hard to peg a fair market value for a bot.  Don't overpay for an overly simplistic bot that will only be productive for a few more days!

I've decided not to distribute my bot in any form to anyone until at least the re-target issue and map resetting annoyance are both resolved.

[HunterMinerCrafter]

I have updated moto-explorer(yeah, i still belive in moto).

Page with address is more usable now. Added new page with richest addresses: http://moto-explorer.fvds.ru/addresses_richest.php

If you like it, send me a few motocoins here: MoaSd7n8jRSG8JNJVkRdvjDVSgBFpoKGRX9

Nice.  Botters like myself probably don't show up on this list because addresses have only 20moto each, heh. I'm assuming the largest accounts are devs and ccex.

Could you add the ability to display (or just pull via rpc) the PoW information for a block?  I'm working on a web based replay viewer and it would be nice to be able to pull the proofs from the explorer.

[gogomymoto]

Could you add the ability to display (or just pull via rpc) the PoW information for a block?  I'm working on a web based replay viewer and it would be nice to be able to pull the proofs from the explorer.

I know nothing about PoW ... Can you explain how i can get it via rpc or some another way? I don't see any relevant data in `getblock` rpc-call.

[HunterMinerCrafter]

I know nothing about PoW ... Can you explain how i can get it via rpc or some another way? I don't see any relevant data in `getblock` rpc-call.

The relevant data is in the getblock results in the fields like nonce, frames, inputs.  Actually just wrapping the getblock call should be enough to be able to reconstruct the block and proof, I'd think.

[gogomymoto]

I know nothing about PoW ... Can you explain how i can get it via rpc or some another way? I don't see any relevant data in `getblock` rpc-call.

The relevant data is in the getblock results in the fields like nonce, frames, inputs.  Actually just wrapping the getblock call should be enough to be able to reconstruct the block and proof, I'd think.

Which one is PoW? You can see the same in Help->Debug Window->Console

Code:

>getblock 62c31233f875cc325abfd70433e1c1da95b1eda20cb1b5711b586b1f6a1caa65 
>{
"hash" : "62c31233f875cc325abfd70433e1c1da95b1eda20cb1b5711b586b1f6a1caa65",
"confirmations" : 20925,
"size" : 266,
"height" : 111,
"version" : 2,
"merkleroot" : "ac2c77e1d8dce09788da52a223ae7463c23d64d8e22590b977e52a4d832f8f8c",
"tx" : [
"ac2c77e1d8dce09788da52a223ae7463c23d64d8e22590b977e52a4d832f8f8c"
],
"time" : 1400632978,
"bits" : "00003a98",
"difficulty" : 1.00000000,
"previousblockhash" : "9abdce34057feba739cc0d9808ab34c29ebd3d9ae8888ca078fd4430dfb349a4",
"nextblockhash" : "db4f2e549c4c6d361b571edb88283e03d4c3917d956c6e779b6c0b28f8b40a79"
}

[HunterMinerCrafter]

Which one is PoW? You can see the same in Help->Debug Window->Console

Code:

>getblock 62c31233f875cc325abfd70433e1c1da95b1eda20cb1b5711b586b1f6a1caa65 
>{
"hash" : "62c31233f875cc325abfd70433e1c1da95b1eda20cb1b5711b586b1f6a1caa65",
"confirmations" : 20925,
"size" : 266,
"height" : 111,
"version" : 2,
"merkleroot" : "ac2c77e1d8dce09788da52a223ae7463c23d64d8e22590b977e52a4d832f8f8c",
"tx" : [
"ac2c77e1d8dce09788da52a223ae7463c23d64d8e22590b977e52a4d832f8f8c"
],
"time" : 1400632978,
"bits" : "00003a98",
"difficulty" : 1.00000000,
"previousblockhash" : "9abdce34057feba739cc0d9808ab34c29ebd3d9ae8888ca078fd4430dfb349a4",
"nextblockhash" : "db4f2e549c4c6d361b571edb88283e03d4c3917d956c6e779b6c0b28f8b40a79"
}

Odd, when I run getblock on my client (v0.8.7.2-unk-beta on linux (from master clone)) it returns the additional PoW fields.

Maybe you need to update the daemon?

[wilppuse]

Anybody mining now? (without bots, manually)? Price seems to be healing bit by bit, atleast its in old digits now. Glad I bought some when it crashed but if only I had decent volumes there would be some serious profit right now.

[gogomymoto]

Odd, when I run getblock on my client (v0.8.7.2-unk-beta on linux (from master clone)) it returns the additional PoW fields.

Maybe you need to update the daemon?

Done! That was really old version. Moto-explorer's block page updated too.

[coelto]

Anybody mining now? (without bots, manually)? Price seems to be healing bit by bit, atleast its in old digits now. Glad I bought some when it crashed but if only I had decent volumes there would be some serious profit right now.

Yes, and it is not so hard right now (25 sec levels). Some my of friends mining to, but they mine just for fun. But 3-4 June it was very-very hard.  

[HunterMinerCrafter]

Odd, when I run getblock on my client (v0.8.7.2-unk-beta on linux (from master clone)) it returns the additional PoW fields.

Maybe you need to update the daemon?

Done! That was really old version. Moto-explorer's block page updated too.

Cool! Thanks!  Even independent of my efforts on a web viewer (which I'm now told there is no more bounty available for, btw) this is handy!  It is interesting that even just flipping through blocks by hand you can see certain bots' "patterns" in their input data.

When I finish the replay viewer you should integrate it as well (it is all client side JS with emscripten, so you could more or less just "drop it in" to the page) so people can have everything in one place.