yes, sure, it's not important. I find out this problem when i read every blockhead into memory and sort by nTime.
I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes.
But today, I find out the block# 301596, the nTime is wrong more than 3 hours.
I think we should resolve this later, how about some miner give a nTime = 2030year tomorrow.
ofcouse , It's doesn't matter, but just look a little bit ugly.
They can't. The timestamp of a block is not offset more than 2 hours from the network adjusted time which is the median of the time that is retrieved from the nodes. You definitely cannot enforce blocks to be within a small timeframe for a few reasons I can think of:I suppose it's a fast way to retrieve the chain. Yesterday, i find wrong time, just in few minutes.
But today, I find out the block# 301596, the nTime is wrong more than 3 hours.
I think we should resolve this later, how about some miner give a nTime = 2030year tomorrow.
ofcouse , It's doesn't matter, but just look a little bit ugly.
1. Miners include the timestamp in the block header and sometimes, they increase the nonce as a variable before they hit the target.
2. Propagation takes some time.
Add to this: 3. Secure, reliable agreement on a reasonably high-precision network time runs into the very same “General” (hah) problem which mining is intended to solve. Indeed, off-the-cuff, I can think of some constructions which may perhaps maybe could be used to replace mining—if we had secure, reliable high-precision network time agreement. (And if I had wings, and if all cows were identical and spherical...)
No one should be using the timestamp to sort out the block, only the block height.
No one should; but you know, somebody will (and just did). I think there’s a rule somewhere that if you provide a variable value, somebody will (ab)use it for purposes neither foreseen nor supported by the design. I will now wait for someone to use the nonce in some way which requires meaning it does not have.
