Topic: How is date/time determined? (Read 1157 times)
Guess that answers that question. Thanks guys. 
So the timestamp of a new block has to be less than 2 hours in the future, and newer than the median of the timestamps on the previous 11 blocks, which will be about 1 hour in the past.
Then there's this, which rejects blocks with too early a timestamp:
Code:
// Check timestamp against prev
if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
if (GetBlockTime() <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
I havent looked through all the code, but I dont think the timestamp really matters. All that matters is that the solved block includes a hash of all previous blocks, to prove that it really is the next block solved. Right?
The timestamp matters when calculating the difficulty.
I found this, that rejects blocks which have a timestamp more than 2 hours into the future:
Code:
// Check timestamp
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
I havent looked through all the code, but I dont think the timestamp really matters. All that matters is that the solved block includes a hash of all previous blocks, to prove that it really is the next block solved. Right?
First off, there would be no need for such complication. The client is open source, so I can bypass all the p2p date averaging and use whatever timestamp I want in the blocks I find.
I think, however, that when a new block is published, it won't be accepted if the timestamp isn't reasonable.
I'll see if I can find the relevant code.
I think, however, that when a new block is published, it won't be accepted if the timestamp isn't reasonable.
I'll see if I can find the relevant code.
Excellent dooglus, thanks. I was hoping there was some sort of peer-averaging solution like that in place.
Next question: Could a potential attack be launched on bitcoins that involves having the block-finder node connected only to certain nodes, and have the collective time of all of those nodes set to a rather obscure time period, either in the future or the past? In other words, what happens if someone publishes a block with a timestamp of 3:00 PM 1/1/1970? Is that going to screw anything up?
Next question: Could a potential attack be launched on bitcoins that involves having the block-finder node connected only to certain nodes, and have the collective time of all of those nodes set to a rather obscure time period, either in the future or the past? In other words, what happens if someone publishes a block with a timestamp of 3:00 PM 1/1/1970? Is that going to screw anything up?
Well, I know they're anchored to UTC, but where do they get the UTC time from? An official time server? Or the block-creator's local system time?
I think what happens is your client asks all the other clients it talks to what they think the time is, and keeps a list of the offsets between them and what it thinks the time is. It then uses the middle of that list as the real time.
For example, in .bitcoin/debug.log I see:
Code:
Added time data, samples 59, offset +8 (+0 minutes)
-31539317 -156 -148 -115 -99 -89 -80 -77 -30 -29 -28 -22 -21 -19 -18 -16 -16 -12 -12 -11 -11 -9 -8 -7 -7 -6 -6 -5 -4 -2 -2 -1 -1 -1 +0 +0 +0 +0 +0 +1 +1 +1 +1 +2 +2 +2 +2 +3 +3 +3 +4 +5 +6 +8 +8 +9 +15 +31 +245 | nTimeOffset = -2 (+0 minutes)
-31539317 -156 -148 -115 -99 -89 -80 -77 -30 -29 -28 -22 -21 -19 -18 -16 -16 -12 -12 -11 -11 -9 -8 -7 -7 -6 -6 -5 -4 -2 -2 -1 -1 -1 +0 +0 +0 +0 +0 +1 +1 +1 +1 +2 +2 +2 +2 +3 +3 +3 +4 +5 +6 +8 +8 +9 +15 +31 +245 | nTimeOffset = -2 (+0 minutes)
The client has got 59 different times from peers and those are the offsets from my clock in seconds.
5 of them agreed with my client to the nearest second. Most clients agreed to within a minute. A few were out by 2 to 5 minutes, and one guy doesn't know what year it is (365*24*60*60 = 31536000). The middle of that list of 59 time offsets is -2, and so 2 seconds is added (or subtracted?) from my computer clock to get the 'real' time.
Well, I know they're anchored to UTC, but where do they get the UTC time from? An official time server? Or the block-creator's local system time?
Where does this time originate?
Time originated with the big band where time and space were created. It is the fourth dimension, along with width, height, and length that we can observe without instruments.
Most time stamps in the bitcoin realm are UTC anchored.
Just curious how date/time is determined for things in bitcoin that require a timestamp, like a block.
For instance, block #134280 was mined at 2011-07-01 22:20:13. Blockexplorer says this number should not be relied upon. And yet, it seems to be relied upon to help calculate the next difficulty.
Where does this time originate? From the system time of the node that discovers the block? What if that time is wrong? Significantly wrong? Will it screw anything up in the blockchain?
For instance, block #134280 was mined at 2011-07-01 22:20:13. Blockexplorer says this number should not be relied upon. And yet, it seems to be relied upon to help calculate the next difficulty.
Where does this time originate? From the system time of the node that discovers the block? What if that time is wrong? Significantly wrong? Will it screw anything up in the blockchain?
Jump to: