Take the 2-minute tour ×
Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It's 100% free, no registration required.

I was rather surprised when I read about the bitcoin's block header time field is only 32 bit. Even if it is unsigned (it is) it only get us 68 more years than the Y2K38 problem. What will happen then, will we need to change the protocol? Can we? What would it imply then?

Why at first Satoshi did not put a 64 bit timestamp at first was that intended?

share|improve this question
    
Could the client detect that it's wrapped somehow and just start again from 0, making use of some other data (eg block number) to figure out whether it's a wrapped number or not? –  Highly Irregular Jan 31 '13 at 20:55
1  
There is no such thing as the block number in the block's header. And at 0 time we are at 1970-01-01 00:00 and computer have no other way to determine the actual date. 0 being lower than the last date no node will accept the block. –  Gopoi Jan 31 '13 at 20:58

2 Answers 2

up vote 5 down vote accepted

2^32 seconds is 136 years. So, this will become a problem in the year 2106. However, even at that point, there are things that we can do to fix the problem.

While it is technically correct that the block number is not encoded in each block header, the block number can easily be inferred. Each block header has the hash of the previous block header. If you follow this back far enough, you'll get to the genesis block. You don't even need to download the entire transaction history, just the block headers.

Okay, so we've got the block number, and the date field. Now, we make a rule that on block 4786000 and all later blocks (which will land at about 2100) the date field will be interpreted to be 100 years later. Block 4786000 will state a date of 2000, but because we made this rule well in advance (we did make it well in advance, right?) all of the clients will know that the date actually means 2100.

Thus, we have bought ourselves another 100 years. On block 9572000, we can do exactly the same thing.

share|improve this answer
    
You would then change the version number to make sure anyone will follow that change of date reference...seems nice. –  Gopoi Jan 31 '13 at 23:40
1  
You could, but you don't really need to. The fact that they didn't object to the "earlier" date proves that they are running the new client. And plus, the version field is only 4 bytes, so you'd have the same problem in 100*2^32 years. ;) –  Nick ODell Feb 1 '13 at 2:21
    
First we would change the version only once, as the rule would be fixed at a certain number of block afterwards. –  Gopoi Feb 1 '13 at 2:24

We will need to change the protocol, because if we let things go node will never accept any block past the wrap around.

The protocol can be changed because of the version field but we need a consensus of the most part of the network.

What will happen then? Anything application specific that cannot change the way it works; i.e. all those ASICS (not yet released), will become obsolete because they are made to calculate hash with a 80 bytes header.

But it all is far in the future we will have time to prepare our self.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.