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?

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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