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!