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

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


It is hard to say how this will work in practice. Every miner will try to set time in their blocks as far in the future as they think network will accept because it allows them to use simpler solutions. 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.

how to play?and someone say it is difficult

So, dev, what about target distance instead of target time?

wtf? it was obvious this would happen
You should put it as an advantage, not as something unfortunate: it's the coin that rewards AI research!
( better playing bots-> more reward ) -> the coin encourages designing of better bots

I didn't have time to read the difficulty adjustment discussion, however you should take this into account instead of trying to do something that favors humans or somehow attempts to limit bots. (why? because you will fail - bots won at chess, like, 17 years ago. Humans may still win at Arimaa, but that's in a full game, not in something that should be done in 60 seconds and verified quickly).

Its so quiet. WTS 2800 moto for 0.1 BTC   

Basically I did this http://jheusser.github.io/2013/02/03/satcoin.html but for motocoin's PoW instead of SHA collision.

The "problem" with this approach (which actually makes moto far more secure than btc against this kind of approach) is the very large breadth of multipliers involved in the moto calculations.

TL;DR Working a physics solution backwards as has been proposed earlier is not a viable approach to machine mining at this time and we can infer from this that it is unlikely that any alternative approach will beat contemporary general purpose AI algorithms like annealing per-challenge (which is what *all* of the winning bots seem to be using right now, lol) at least without very fancy specialized tricks of mathematics. (edit: or in other words we can say confidently for awhile that the moto work challenge itself is sufficiently hard for computers.  Harder than most any traditional hashing, by quite a bit.  "ASIC resistant" isn't even the name for it.)

What time window would you propose?  BTC allows 70 minutes, iirc. (EDIT: 70 minutes under normal circumstances, 140 minutes under timejacking attack.)

BitCoin is also using time paradigm to calculate thresholds. And it is also possible in bitcoin to form a huge chain pointing to the future and this chain will be declined because it is pointing to the future. The difference is not very big when we talk about the last block only. If some crazy miner will ignore this and will keep mining based on a block from the future he will finally end up with short chain when time will catch it up. This is not efficient all the gamers will try to use most recent blocks. Like in BitCoin.

I got 37 frames pee second using basic overflow script that calculetes point overflow in block stream. From that point it was just matter of writing algorithm that evolves better solutions.

.
.
.
.
.
.
.
.
.
.
.
.
.
I have no idea what I was just wrote.
.
.
.
.
This discussion has been now for a while waaaaaay over my head.

I've been playing around a bit with directly regressive solutions (basically "running the physics backwards" to derive the input moves) using cprover tools and a couple of different backend solvers.  At least with naive approaches, it does not look like this sort of search will be competitive any time soon, so that is good.  Basically the sat solvers will get, after some quick optimizations, around 5-10 frames per second per core of my i7-3630QM CPU @ 2.40GHz.

Probably something specialized could greatly outperform this, but I would guess probably still would not be competitive at this time.  (If someone can do significantly better performance than this I'd really like to see it!)

This is just the problem, "remote future" is effectively undefined because "current time" which it is relative to is effectively undefined.  The allowed values for "remote future" would have to be quite remote, and quite broad.  As such, I don't feel that this would accomplish what you think.

Specifically, the problem is that the allowed range of valid wall clock times has to be somewhat large relative to the block interval, or problems quickly arise.  However, a good balance is important because making it too large makes traditional time warp based 51% attacks more likely to success.  I agree that we might possibly want the range to be smaller for various reasons, but disagree that it needs to be biased toward the past and in fact think doing so might be very problematic.


Agreed on both points.  The definition of "perfect" has to be very very loose though.


Until if/when wall clock catches up to him, of course.  I agree that part of this is good for all.


Not sure I follow this bit, please can you rephrase?

EDIT: did you mean on confirmations, not on acceptance?

I am not going to say that an individual block time shall be perfectly valid. The only restriction that the top of a main chain shall not end in remote future. There is no error accumulation issue then and perfect time synchronization is not critical. Even if some client will accept a block from future he will not be able to compete with miners who accepted and start mining from earlier blocks because his chain will be longer than their chain.

Now we have transaction acceptance criteria that it should be included in a chain longer than say 10 blocks. We can also add that those blocks shall not be from the future.

The whole point of a blockchain is basically the fact that you can't rely on wall clock time for anything at all.  Other clients can't verify that time specified on a block is lower than "the current time" because for all participants "the current time" is actually just a (large) set of possible times, and is effectively undefined for most purposes.  The one thing we very much do not (and can not) have consensus about is wall clock time.  Our only reliable measurements of times are blockchain time which has a probabilistic constant frequency, assuming difficulty retarget is correct, and (in the special case of moto) bike run time which has arbitrary frequency.

No solution which requires some agreement about relative wall clock times can work.

CBlockIndex structure already have nTime field in it. I am not sure who is filling it. Even if it is not a part of transferred block header then it can be added there. Miner can set this value while he broadcast a block he mined. "Like look guys I have a block started from that block, I used this time to mine it, and there is a solution that fit under the floating threshold, feel free to use it as the base for your mining". Other clients shall only verify that the time is lower than the current time say GMT it doesn't matter what global time will be taken in account the difference in few secs is not crucial for a single block.

It can still be interesting among miners to broadcast blocks from the future and start mining from that blocks to be the first one who continue the chain if no faster block will be found. But this is already up to miners what block to choose as the base yet no block from the future shall be considered valid by clients.

None of it is nonsense, just statistical fact from the chain.

I suspect that no-one is performing an attack because there is no gain to be had from it... and this is the very definition of secure.  Someone could make a very very large spend and destroy BTC tomorrow, as well, but it doesn't happen simply because there is no rational motivation to do so.  I think the state of MOTO is no different.

As more potential for gain appears the hashing efforts of the attacker's competition for blocks should also increase proportionally, keeping the expectation of the attacker relatively low.


Bot miners don't use their full potential for the same reason mining pools tend not to throw all of their hashing strength at a brand new coin right away - nobody wants to be the one to precipitate the "race to the bottom" too soon.

In MOTO, we also have a second rationale for the bot miners to scale as slowly as possible, to allow opportunity for skilled human miners to continue to participate.

If an attacker suddenly comes in with a datacenter and no throttling on their bots, I'll just come in with two datacenters and no throttling on my bots, and the only thing that will really change from our current state is that even the most skilled players will then be screwed out of any chance of subsidy.... the network itself will remain strong and secure.

Can we stay focused on the real topics at hand, which are how to properly adjust difficulty target (let's just return to a more classic retarget with a small upward pressure to prevent un-mine-ability?) and how to make the constant map resets not hamper players so much (let's just give them N blocks to choose from for their seed?) and worry about these more philosophical debates after that?

EDIT: I should note something on a point that DeepCrypto brought up earlier, about the safety of added upward pressure.  With most coins, adding an upward pressure would be particularly problematic because of the relationship between difficulty curve and distribution of the total finite supply. MOTO attempts to maintain no such relationship as there is virtually an infinite supply. (Presuming humanity persists long enough that overflows become a concern (nothing in our universe is really infinite, co-moving visibility and all) I think we could safely just bump bit widths up as necessary.)

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

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.


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?

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.

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.

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.