As far as I know, some popular OS's still use local time for their hardware clock instead of UTC.
This is a problem during transistions between daylight savings time and standard time. Normally, the NTP server is not completely trusted and large, sudden shifts in time are avoided. If you are dual-booting with you hardware clock set to local time, you OS has no way of knowing if the other has changed the clock or not (unless you take the time to disable automatic time changes).
TL;DR: unless your hardware clock is set to UTC, it is entirely reasonable to expect your clock to be off by up to an hour about twice a year. Even if you are using NTP.
Topic: Is something wrong with the blockchain (Read 1912 times)
There is a hardcoded limit implemented right now, 2 hours. So what would be the difference between 2 hours and 1 minute?
The difference would be that the probability of inadvertently entering a situation where large parts of the network disagree over a block's validity would be much, much lower.Quote
Well, there is some bleeding edge new technology called NTP. Oops, we have this since well before '85. http://en.wikipedia.org/wiki/Network_Time_Protocol But of course using NTP would force us to have some online connection (aka internet) maybe once a day to correct the time drift of the built-in real time clock. Wait, Bitcoin needs an online connection anyway, so the legitimate is why does Bitcoin not use NTP?
Nothing prevents people from using NTP to mine blocks with accurate timestamps. If the question is why Bitcoin doesn't force people to provide more accurate timestamps it's because there's no technical requirement for them and it increases the risk of inadvertently entering a situation where large parts of the network disagree over a block's validity. 
There was some discussion of this issue on the mailing list recently. It's worth review if you're seriously investigating this. The upshot is that throwing this sort of change in could fork the block chain or have other unexpected effects.
http://sourceforge.net/mailarchive/message.php?msg_id=28082081
http://sourceforge.net/mailarchive/message.php?msg_id=28082081
It doesn't look right. It requires further investigation. Anyone willing!?!?!?!
Trivial time range shrinking from starting October 2011 (2 hours) and ending March 2012 (1 minute).
Current code:
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
New code:
Code is just typed in, untested. So it probably contains bugs
Current code:
Code:
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
New code:
Code:
// Check timestamp
int64 range = 1333000000 - GetBlockTime();
if (range < 0)
range = 0;
range /= 2048;
if (range > 2 * 60 * 60 - 60)
range = 2 * 60 * 60 - 60;
range += 60;
if (GetBlockTime() > GetAdjustedTime() + range)
return error("CheckBlock() : block timestamp too far in the future");
int64 range = 1333000000 - GetBlockTime();
if (range < 0)
range = 0;
range /= 2048;
if (range > 2 * 60 * 60 - 60)
range = 2 * 60 * 60 - 60;
range += 60;
if (GetBlockTime() > GetAdjustedTime() + range)
return error("CheckBlock() : block timestamp too far in the future");
Code is just typed in, untested. So it probably contains bugs
If the protocol demanded strictly-increasing timestamps, what should you do if a block shows up whose timestamp is one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?
Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.
Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.
There is a hardcoded limit implemented right now, 2 hours. So what would be the difference between 2 hours and 1 minute? In both cases it is a clear cut. Either the block is declared valid or not valid. So today the current question is "what should you do if a block shows up whose timestamp is 2 hours and one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?" Looking at the current code, it is clear that this block would just be invalid.
Now even if this would be 20 years ago, I would say 2 hours is way too much. I think it would take years for an average real time clock to accumulate a clock drift of 2 hours. So I guess, the only reason we still have 2 hours is that some pool operator(s?) like to play with the timestamps - I highly doubt that anyone else mining is not using the correct time:
Well, there is some bleeding edge new technology called NTP. Oops, we have this since well before '85. http://en.wikipedia.org/wiki/Network_Time_Protocol But of course using NTP would force us to have some online connection (aka internet) maybe once a day to correct the time drift of the built-in real time clock. Wait, Bitcoin needs an online connection anyway, so the legitimate is why does Bitcoin not use NTP?
If the protocol demanded strictly-increasing timestamps, what should you do if a block shows up whose timestamp is one minute ahead of what you think the time is? Should you stop mining for a minute? Should you mine blocks with a timestamp you believe is wrong?
Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.
Because it is important that the network as a whole agree on whether a block is valid, it doesn't make sense to insist on monotonically increasing timestamps.
Not really, block timestamps are taken from the computer that solves the block and have no special meaning within Bitcoin. The nodes in the Bitcoin network accept blocks which are at most 2 hours off their own clock, so it is perfectly possible to see the next block having a timestamp before the last block.
There's also talk about some miners (pools) deliberately offsetting their clocks.
There's also talk about some miners (pools) deliberately offsetting their clocks.
145420
145419
Something wrong?
Code:
http://blockexplorer.com/block/00000000000002cd0003629d5e515222261fd290af22012c9d52375c7778f5ea
[b]Time?: 2011-09-15 06:55:09[/b]
[b]Time?: 2011-09-15 06:55:09[/b]
145419
Code:
http://blockexplorer.com/block/0000000000000078ce8d6a3cacbf388d01102abed511dd8d798f75878c21a273
[b]Time?: 2011-09-15 07:16:37[/b]
[b]Time?: 2011-09-15 07:16:37[/b]
Something wrong?
Jump to: