[ANN][MOTO] Motocoin

[HunterMinerCrafter]

This is a complete nonsense. The only reason why it works now is because no one is performing an attack.

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.

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.

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

[1715412910]

1715412910

[1715412910]

1715412910

[DeepCryptoanalist3]

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?

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.

[HunterMinerCrafter]

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?

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.

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.

[DeepCryptoanalist3]

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?

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.

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.

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.

[HunterMinerCrafter]

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.

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.

There is no error accumulation issue then and perfect time synchronization is not critical.

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

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.

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

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.

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

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

[HunterMinerCrafter]

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

[wilppuse]

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.

[DeepCryptoanalist3]

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.

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.

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.

[HunterMinerCrafter]

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.

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.

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.

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

[HunterMinerCrafter]

This discussion has been now for a while waaaaaay over my head.

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

[e1ghtSpace]

Its so quiet. WTS 2800 moto for 0.1 BTC   

[gatra]

Unfortunately, currently it is dominated by bots.
:[/b] Previously proof-of-thought was used instead of proof-of-play.

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

[TheXpert]

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

[foob6]

how to play?and someone say it is difficult

[WilliamLie2]

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

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

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.

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.

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.

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.

[HunterMinerCrafter]

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

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

I think he means to increase map size with difficulty.

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.

Right, this is precisely why I am ok with the notion of an acceptance window, but not ok with a bias against the future on that window.  All that does is gives incentive to a miner to push their own timestamps forward, both to maximize their own set of acceptable solutions, and to minimize the opportunity for other miners by "pushing the others out" with their own blocks.  If block production rate was high enough that "batch submitting" blocks in sections was desirable a miner might even be inclined to try to quickly mine multiple short forks locally, and submit whichever ends at the furthest timestamp out.  This is not a good scenario for the network to be in as normal operation (as it actually disincentivizes mining anything besides coinbase tx, among other things!) and these issues just scratch the surface of the potential for problems.  (The "deeper" problems are basically related to the fact that in the same way a miner can rewrite history on difficulty they could similarly rewrite history on timestamp anyway, so the time-warp is just moved from difficulty manipulation to timestamp+difficulty manipulation.  You basically just end up reducing the depth to which time-warp history rewrites can occur but actually make it easier to accomplish the warp attack itself.)

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

[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'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?

[wood7]

who can tell me how to play?i want to play,lol

[WilliamLie2]

who can tell me how to play?i want to play,lol

http://motocoin.org/#mine

[HunterMinerCrafter]

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?