Bitcoin Forum
December 08, 2016, 04:22:03 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: How is date/time determined?  (Read 967 times)
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 01, 2011, 10:28:36 PM
 #1

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?
1481214123
Hero Member
*
Offline Offline

Posts: 1481214123

View Profile Personal Message (Offline)

Ignore
1481214123
Reply with quote  #2

1481214123
Report to moderator
1481214123
Hero Member
*
Offline Offline

Posts: 1481214123

View Profile Personal Message (Offline)

Ignore
1481214123
Reply with quote  #2

1481214123
Report to moderator
1481214123
Hero Member
*
Offline Offline

Posts: 1481214123

View Profile Personal Message (Offline)

Ignore
1481214123
Reply with quote  #2

1481214123
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481214123
Hero Member
*
Offline Offline

Posts: 1481214123

View Profile Personal Message (Offline)

Ignore
1481214123
Reply with quote  #2

1481214123
Report to moderator
1481214123
Hero Member
*
Offline Offline

Posts: 1481214123

View Profile Personal Message (Offline)

Ignore
1481214123
Reply with quote  #2

1481214123
Report to moderator
MeSarah
Full Member
***
Offline Offline

Activity: 154


View Profile
July 02, 2011, 12:10:07 AM
 #2

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.

60 GH/s BFL Single SC - Pre-Order Yours Today!
`````` Only $1299.99 - butterflylabs.com ``````
SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 02, 2011, 12:25:23 AM
 #3

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?
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 02, 2011, 12:58:02 AM
 #4

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)

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.

SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 02, 2011, 01:01:34 AM
 #5

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?
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 02, 2011, 01:29:41 AM
 #6

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.

mouse
Jr. Member
*
Offline Offline

Activity: 56



View Profile
July 02, 2011, 01:32:55 AM
 #7

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?

Any intelligent fool can make things bigger, more complex and more violent. It takes a touch of genius and a lot of courage to move in the opposite direction.
dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 02, 2011, 01:35:45 AM
 #8

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");

dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 02, 2011, 01:38:53 AM
 #9

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");

dooglus
Legendary
*
Offline Offline

Activity: 2002



View Profile
July 02, 2011, 01:53:24 AM
 #10

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.

SgtSpike
Legendary
*
Offline Offline

Activity: 1344



View Profile
July 02, 2011, 03:28:24 AM
 #11

Guess that answers that question.  Thanks guys.  Smiley
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2506


View Profile
July 02, 2011, 03:31:36 AM
 #12

https://en.bitcoin.it/wiki/Block_timestamp

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!