7

Is there a plan in place for when the inevitable 32-bit overflow of Unix timestamps occurs?

How much will this impact existing blocks that are timestamped with Unix Epoch times?

Improve this question
1
  • 1
    The OpenBSD guys have solved this topic already: "From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready and will run well beyond Tue Jan 19 03:14:07 2038 UTC."
    – pebwindkraft
    Sep 13, 2018 at 19:46

1 Answer 1

Reset to default
15

The 32-bit signed integer timestamp runs out in 2038. But Bitcoin uses a 32-bit unsigned integer for the timestamp. That runs out it the year 2106. We'll have to find a solution by then, not by 2038. Since that is still a long ways off, there is no plan for changing the timestamps yet.

Whatever happens would not affect existing blocks. The same thing would happen as with any other fork: blocks prior to the activation block are verified with the old rules, and blocks following activation are verified with the new ones. So old blocks would use the current timestamp stuff and new ones would use whatever new scheme is created.

Improve this answer
1
  • 3
    In principle, nothing has to be changed in the protocol, since AFAIK all that's ever relevant is the difference between timestamps of blocks with 2016 or fewer blocks in between. If the code does its arithmetic correctly, everything would be fine unless the timestamps wrap around twice within that span. If it takes 136 years to generate 2016 blocks, we have bigger problems.
    – Nate Eldredge
    Sep 13, 2018 at 19:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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