Quote from: HunterMinerCrafter on June 07, 2014, 03:53:16 PM

Quote from: DeepCryptoanalist3 on June 07, 2014, 03:33:46 PM

Quote from: WilliamLie2 on June 07, 2014, 02:57:11 PM

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.