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

http://motocoin.org/#mine

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

What do you mean by bias?

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?

I think he means to increase map size with difficulty.


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!