<p>There is a fairly trivial solution, which is technically a hard fork, but doesn't require changing fields.</p>
<p>The idea is that the timestamp is indeed treated as a 64-bit value, but only its lower 32 bits (which are then allowed to overflow) are stored in the block header. When a block's 32-bit timestamp is sufficiently much lower than the previous blocks' 32-bit timestamp, it is assumed to have overflowed, and 2^32 is added to the interpreted 64-bit timestamp.</p>

CC BY-SA 4.0
2021-09-23T13:18:55.470Z
2021-09-23T13:18:55.470Z
Pieter Wuille
<p>In the protocol there are multiple timestamp fields with varying lengths. For example a 4 byte unix timestamp would overflow in the year 2106. Will a hard fork be needed to deal with this issue in the coming century?</p>

<blockchain-fork><timestamp>
Will a hard fork be required to change timestamp fields?
Chiru
# Will a hard fork be required to change timestamp fields?

(Asked by: username_0 on 2021-06-03)

In the protocol there are multiple timestamp fields with varying lengths. For example a 4 byte unix timestamp would overflow in the year 2106. Will a hard fork be needed to deal with this issue in the coming century?

**Tags:** blockchain-fork, timestamp


---

## 1 answers

### Answer by username_1 on 2021-09-23. Score: 6

There is a fairly trivial solution, which is technically a hard fork, but doesn't require changing fields.

The idea is that the timestamp is indeed treated as a 64-bit value, but only its lower 32 bits (which are then allowed to overflow) are stored in the block header. When a block's 32-bit timestamp is sufficiently much lower than the previous blocks' 32-bit timestamp, it is assumed to have overflowed, and 2^32 is added to the interpreted 64-bit timestamp.


---

