[ANN][MOTO] Motocoin

[Jacqul]

HunterMinerCrafter, WilliamLie2, you guys are awesome.
I have enjoyed just about everything with this coin so far.
Thanks for the nonce graphics as well WilliamLie, very interesting.

[1714192787]

1714192787

[1714192787]

1714192787

[1714192787]

1714192787

[HunterMinerCrafter]

EDIT: Wait, maybe I do see what you mean after all... basically "median" is both not actual median, and also ultimately has no impact on the retarget if target==actual. (Or is very very close.)  Am I on the right track now?

actual has no impact on the retarget if current==median.

Ah, yes, so it works both ways. (Or rather fails both ways, heh.)

[HunterMinerCrafter]

Nice. There is a vulnerability in motocoin that can be exploited by a bot owner to easily make a blockchain fork. Anyway this is too risky to invest money in this coin unless they close the bug.

How do you propose to fix that bug? You can't just decrease target time if there were no maps that were completed in time less than new target time because you may just accidently decrease it to a point when it becomes unachievable.

(Edit: removed poorly worded and distracting junk.  I'll try to better convey what I meant later, after more pressing matters are handled.)

Another approach would be to do something along the lines of a gravity well, or to introduce a small difficulty-reduction-over-time-by-default.  (When multi-pools started destroying chains inadvertently these solutions became popular to keep chains from stalling out.  I think this particular conundrum is similar.)

[DeepCryptoanalist3]

Nice. There is a vulnerability in motocoin that can be exploited by a bot owner to easily make a blockchain fork. Anyway this is too risky to invest money in this coin unless they close the bug.

How do you propose to fix that bug? You can't just decrease target time if there were no maps that were completed in time less than new target time because you may just accidently decrease it to a point when it becomes unachievable.

We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.

[DeepCryptoanalist3]

I think you just answered your own question, sort of: simply don't decrease below the lowest threshold ever seen in a valid block. (Whether that block is in the main chain or otherwise!)

This is absolutely the same flawed idea as we have now. You can build a long chain started from the genesis block and each solution in a chain will be slow and far from optimal.

[HunterMinerCrafter]

nevermind, ignore me.  I must be getting tired.

[Jacqul]

Would it be possible to use the nonce patterns in identification of human played maps/blocks giving them priority?
Would it be possible to increase the complexity of the maps with higher nonce values?

If there is a way to force bots to emulate the way humans play, would that mean safety and survival of the coin?

[HunterMinerCrafter]

Would it be possible to use the nonce patterns in identification of human played maps/blocks giving them priority?

Not really, it will become increasingly hard to discern bots from humans over time anyway.

Would it be possible to increase the complexity of the maps with higher nonce values?

This wouldn't be much different from just limiting the number of maps available, I suspect.

If there is a way to force bots to emulate the way humans play, would that mean safety and survival of the coin?

Yes, but IMO as long as the chain is still hashing and no-one has demonstrated the proposed difficulty time-warp the coin is still safe and surviving, for now.

Though this could change entirely at any moment, I suppose.

[bittick]

like now. you get 22 seconds to complete the map. This is humanly impossible having in mind the complexity of the maps.
nobody will play this except bots.

the 60 second target should not be variant.

[balbes]

Hello!
I've got a problem.I can't launch the game.
In the log there are some entries:
2014-06-07 10:03:06 trying connection 5.158.233.102:13107 lastseen=4,5hrs
2014-06-07 10:03:06 CreateNewBlock(): total size 1000
2014-06-07 10:03:07 CreateNewBlock(): total size 1000
2014-06-07 10:03:07 CreateNewBlock(): total size 1000
2014-06-07 10:03:08 CreateNewBlock(): total size 1000
2014-06-07 10:03:08 CreateNewBlock(): total size 1000
2014-06-07 10:03:09 CreateNewBlock(): total size 1000
2014-06-07 10:03:09 CreateNewBlock(): total size 1000
2014-06-07 10:03:10 CreateNewBlock(): total size 1000
2014-06-07 10:03:10 CreateNewBlock(): total size 1000
2014-06-07 10:03:11 CreateNewBlock(): total size 1000
2014-06-07 10:03:11 connection timeout
WTF?what am I doing wrong?

[WilliamLie2]

We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.

How can you reliable measure time interval between adjacent blocks? I don't think there is a way.

Would it be possible to use the nonce patterns in identification of human played maps/blocks giving them priority?
Would it be possible to increase the complexity of the maps with higher nonce values?

If there is a way to force bots to emulate the way humans play, would that mean safety and survival of the coin?

I'm very tired of answering the same questions. Nonce is useless, you can just change your coinbase address and always use nonce=0.

[WilliamLie2]

Yes, but IMO as long as the chain is still hashing and no-one has demonstrated the proposed difficulty time-warp the coin is still safe and surviving, for now.

Though this could change entirely at any moment, I suppose.

It is not safe. Bot owners (including you) can fork the whole blockchain, it is not what people call safety.

[HunterMinerCrafter]

Hello!
I've got a problem.I can't launch the game.
In the log there are some entries:
2014-06-07 10:03:06 trying connection 5.158.233.102:13107 lastseen=4,5hrs
2014-06-07 10:03:06 CreateNewBlock(): total size 1000
2014-06-07 10:03:07 CreateNewBlock(): total size 1000
2014-06-07 10:03:07 CreateNewBlock(): total size 1000
2014-06-07 10:03:08 CreateNewBlock(): total size 1000
2014-06-07 10:03:08 CreateNewBlock(): total size 1000
2014-06-07 10:03:09 CreateNewBlock(): total size 1000
2014-06-07 10:03:09 CreateNewBlock(): total size 1000
2014-06-07 10:03:10 CreateNewBlock(): total size 1000
2014-06-07 10:03:10 CreateNewBlock(): total size 1000
2014-06-07 10:03:11 CreateNewBlock(): total size 1000
2014-06-07 10:03:11 connection timeout
WTF?what am I doing wrong?

Are you able to run the "motogame" binary directly?  If you run it from a console does it generate any errors?

[balbes]

motogame did not start.It appear a dialog that inform me that app crashed.

[HunterMinerCrafter]

Yes, but IMO as long as the chain is still hashing and no-one has demonstrated the proposed difficulty time-warp the coin is still safe and surviving, for now.

Though this could change entirely at any moment, I suppose.

It is not safe. Bot owners (including you) can fork the whole blockchain, it is not what people call safety.

Only if they can overcome the production rate of the other bot miners, though.  This is, after all, still a form of 51% attack.

Let's look at some facts:
 * To date, our longest fork was 13 blocks, this is *significantly* lower than historical forks of most other "fast" coins, including in particular HUC - the closest coin to moto in many ways.
 * There have been only 10 forks longer than 6 blocks, which is the "traditional" confirmation count for BTC at 10 minute blocks.  (Considering we average only 47 seconds per block since block 8000, we should "expect to need" almost 20 times as many confirmations (120) for the same level of integrity.)
 * The vast majority of forks are simple stales, 1 block forks.  These are entirely to be expected at such a low block interval.

Given these facts I'd argue that (historically, at least) the coin has shown itself to be pretty damned safe and secure!  Personally, I don't know of any other coin at all with such a high transaction confirmation speed and such a low fork rate.

[DeepCryptoanalist3]

Only if they can overcome the production rate of the other bot miners, though.  This is, after all, still a form of 51% attack.

Now there is no complexity growth in block solution task. Without this criteria solutions will become faster and faster. Now bots needs 3 sec to solve a level. With some optimization it will be a fraction of a second. Finally we will came to the point when bot owner will have no aim to share individual blocks among other miners because net lag will be bigger than the block generation time. Bot owners will build series of blocks like 10-100 in a row and throw them into network at once. This is crazy way to go. Complexity threshold should be fixed and tightened to the real time. It should be a race for better and more optimal level solutions.

[kuchitsu]

like now. you get 22 seconds to complete the map. This is humanly impossible having in mind the complexity of the maps.

Nope. I got about 900 MOTO during the last few days by myself. You just have to use F6 a lot (I probably spent as much time on pressing it as on actually playing levels) and optimize your movements well.

[DeepCryptoanalist3]

We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.

How can you reliable measure time interval between adjacent blocks? I don't think there is a way.

The sum of block times in a chain shall be always smaller than the current time. It can be used to let miners to build chains where block will be accepted if it contains a solution passed the threshold deduced from a block separation from previous. For example if a new block is issued in K mins from previous then the solution shall be faster than the square of K. If you want to issue a new block in 10 sec then your solution shall be shorter than (10/60)^2 * 60 = 1,67 seconds, if you want to issue a new block in 30 sec then solution can be already 15 sec long. At one minute mark you will be able to issue one minute long solutions. Then to build a longer chain in the same period of time you will still needs to build it from rather optimal solutions. You wouldn't be able to make a long chain of block whose solutions are inefficient because floating threshold will prohibit it.

[WilliamLie2]

Yes, but IMO as long as the chain is still hashing and no-one has demonstrated the proposed difficulty time-warp the coin is still safe and surviving, for now.

Though this could change entirely at any moment, I suppose.

It is not safe. Bot owners (including you) can fork the whole blockchain, it is not what people call safety.

Only if they can overcome the production rate of the other bot miners, though.  This is, after all, still a form of 51% attack.

Let's look at some facts:
 * To date, our longest fork was 13 blocks, this is *significantly* lower than historical forks of most other "fast" coins, including in particular HUC - the closest coin to moto in many ways.
 * There have been only 10 forks longer than 6 blocks, which is the "traditional" confirmation count for BTC at 10 minute blocks.  (Considering we average only 47 seconds per block since block 8000, we should "expect to need" almost 20 times as many confirmations (120) for the same level of integrity.)
 * The vast majority of forks are simple stales, 1 block forks.  These are entirely to be expected at such a low block interval.

Given these facts I'd argue that (historically, at least) the coin has shown itself to be pretty damned safe and secure!  Personally, I don't know of any other coin at all with such a high transaction confirmation speed and such a low fork rate.

This is a complete nonsense. The only reason why it works now is because no one is performing an attack. Current network difficulty is very low, bots can generate blocks with current difficulty in mere seconds if not faster, using several computers they would be able to do it even faster. Spacing between blocks is now long just because bots don't use their full potential.

We are already very far from original satoshi idea... so I propose to use a floating threshold. If no one is able to find a block in 2 mins then threshold will be increased. Or better say that new block threshold should be somehow linked not only to the previous 2000 blocks and separation between them but also to separation between this block and previous. It is hardly to find any hole in there... looks fine to me at first sight. It may introduce some kind of oscillation but I do not see any big flaw that can be used in attack. If you are issuing new block in just one second then your solution shall be shorter than say 5 second. If you are issuing next block after a five minute of game than your solution can be very slow and not optimal.

How can you reliable measure time interval between adjacent blocks? I don't think there is a way.

The sum of block times in a chain shall be always smaller than the current time. It can be used to let miners to build chains where block will be accepted if it contains a solution passed the threshold deduced from a block separation from previous. For example if a new block is issued in K mins from previous then the solution shall be faster than the square of K. If you want to issue a new block in 10 sec then your solution shall be shorter than (10/60)^2 * 60 = 1,67 seconds, if you want to issue a new block in 30 sec then solution can be already 15 sec long. At one minute mark you will be able to issue one minute long solutions. Then to build a longer chain in the same period of time you will still needs to build it from rather optimal solutions. You wouldn't be able to make a long chain of block whose solutions are inefficient because floating threshold will prohibit it.

You still didn't answer my question. How will you measure time interval between adjacent blocks? You are describing what you are going to do with it, but my question is how will you find it?

[HunterMinerCrafter]

Only if they can overcome the production rate of the other bot miners, though.  This is, after all, still a form of 51% attack.

Now there is no complexity growth in block solution task. Without this criteria solutions will become faster and faster. Now bots needs 3 sec to solve a level. With some optimization it will be a fraction of a second. Finally we will came to the point when bot owner will have no aim to share individual blocks among other miners because net lag will be bigger than the block generation time. Bot owners will build series of blocks like 10-100 in a row and throw them into network at once. This is crazy way to go. Complexity threshold should be fixed and tightened to the real time. It should be a race for better and more optimal level solutions.

My point is still valid, even despite the "crazy" outcome.  Presumably as one bot miner gets faster and faster the majority of his competition bot miners will get faster and faster as well, and the difficulty of performing the attack will remain relatively consistent.

I don't believe anyone can currently solve blocks (each time) in 3 seconds.  Or, rather, I think that even with double-spending attacks the potential gain is not worth the current energy spend to do so.  So the only real motivation for throwing this excess of hashing at the network would be to speculate, and I don't expect that some who believes that the value will rise would also attack the network with double-spend, either via your difficulty time warp or via a traditional 51%.  To do so would not be very rational.

So, in other words, we could potentially see some silliness with miners pre-solving and batch submitting multiple blocks and so forth, but I would not expect to see these participants doing so as part of an explicit attack, currently.  The resulting forks might occasionally be a nuisance to users, but not ultimately detrimental to them.  (I'd expect forks to include more or less the same sets of user tx records on both sides of the fork.)