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

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

<p>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.</p>

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

CC BY-SA 3.0
2013-01-31T13:34:06.207Z
2013-01-31T13:34:06.207Z
Gopoi
<p>2^32 seconds is 136 years. So, this will become a problem in the year <em>2106</em>. However, even at that point, there are things that we can do to fix the problem. </p>

<p>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 <a href="https://en.bitcoin.it/wiki/Genesis_block" rel="nofollow">genesis block</a>. You don't even need to download the entire transaction history, just the block headers.</p>

<p>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.</p>

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

CC BY-SA 3.0
2013-01-31T23:40:36.810Z
You would then change the version number to make sure anyone will follow that change of date reference...seems nice.
Gopoi
CC BY-SA 3.0
2013-02-01T02:21:38.373Z
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
CC BY-SA 3.0
2013-02-01T02:24:07.933Z
First we would change the version only once, as the rule would be fixed at a certain number of block afterwards.
Gopoi
CC BY-SA 3.0
2013-01-31T23:34:49.007Z
2015-04-24T17:43:21.467Z
2015-04-24T17:43:21.467Z
Nick ODell
<p>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 <a href="http://en.wikipedia.org/wiki/Year_2038_problem">Y2K38 problem</a>. What will happen then, will we need to change the protocol? Can we? What would it imply then?</p>

<p>Why at first Satoshi did not put a <a href="http://web.archive.org/web/20060408161959/http://unununium.org/articles/uuutime">64 bit timestamp</a> at first was that intended?</p>

CC BY-SA 3.0
2013-01-31T20:55:00.860Z
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
CC BY-SA 3.0
2013-01-31T20:58:42.317Z
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
<protocol>
What will happen when the time field wraps around
Gopoi
# What will happen when the time field wraps around

(Asked by: username_0 on 2013-01-31)

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](http://en.wikipedia.org/wiki/Year_2038_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](http://web.archive.org/web/20060408161959/http://unununium.org/articles/uuutime) at first was that intended?

**Tags:** protocol

> **Comments:**
> **username_1**: 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?  
> **username_0**: 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.  

---

## 2 answers

### Answer by username_2 on 2013-01-31. Score: 8 | Accepted answer

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](https://en.bitcoin.it/wiki/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.

> **Comments:**
> **username_0**: You would then change the version number to make sure anyone will follow that change of date reference...seems nice.  
> **username_2**: 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. ;)  
> **username_0**: First we would change the version only once, as the rule would be fixed at a certain number of block afterwards.  

---

### Answer by username_0 on 2013-01-31. Score: 0

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.


---

