Don't take this the wrong way, but you did get this "minute detail about one of the simpler aspects" wrong.
Sorry, but no, I didn't get anything wrong. I failed to communicate an idea clearly, which I would have spent more effort avoiding if it referred to anything important.
"Right shift by 1 bit" is not the same operation as "divide by two and round down". They obtain the same result if done properly, but have different meta costs, as you helped me demonstrate.
I don't understand. Bit-shift may take less CPU time but it's much more difficult conceptually. The actual operation being done is division by 2 and rounding down, bit-shift is the specific code used to do it.
Do you get what I'm trying to say?
No.
P.S. Read the bold part again. Warning bells should be going off as you do.
Not really. If I were able to predict what the market would do I'd be rich. I just want it to have the tools to find what's most efficient for it, and that's easier to demonstrate.
It is relatively simple to show that 5 seconds between blocks is too short, and that 3600 seconds between blocks is too long. It is much harder to show that 590 or 610 seconds is better than 600, or that 300 or 900 are better than 600.
As you say, it is hard to predict what this system will look like once it gets rolling. Will we be trading one non-optimal block average for a different non-optimal average? Will we be making a system that cycles or floats through a range of values, each just as non-optimal as the others? How can we tell a "good" state from a "bad" state?
It's all about the incentive structure. If we can find a system that allows the people for whom the value actually matters to vote with their feet, we should come up with something good.
Usually I make these points in threads about moving the decimal point, but they really apply to all of the magic numbers. Why 10 minutes? Why 2 weeks? Why 210,000 blocks? The answer is always the same, because they are "good enough" and it is really hard to show that any different numbers would be any better.
I suspect that the same applies here. It seems to me that it is just as hard to show that a dynamic system is any better for this job, and it doesn't just have to be any better, it has to be better enough to pay for the extra complexity costs.
Some magic numbers are more important than others. 21M total bitcoins is unimportant, 100M units per bitcoin is unimportant. 2 weeks is somewhat important. 4 years and 10 minutes are quite important. We can't change 4 years for Bitcoin itself, but maybe we can change 10 minutes.
I agree completely that it is hard to deduce that one value is better than another, but I don't think it's as hard to show that a certain system has the incentives to find an optimal value properly aligned.
Also, even if the dynamic system can't be trusted to be robust, the proposal gives a framework for changing the static block time, if there is ever a consensus that it should be changed.
All that said, unless you want to discuss these things further, I'm willing to bow out here and let you get this thread back on track so that you can finish presenting your idea. I really would like to see the rest of it.
We can discuss it further. Some of the discussion is better deferred until I write about some related ideas. I'm not saying I have all the answers, but I think it's possible to make a useful system out of this.