2
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?
January 19th, 2038: RIP Unix Timestamps
Answers
9
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.
2In 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 – 2018-09-13T19:42:57.593
1The 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 – 2018-09-13T19:46:03.690