Solve year 2106 problem by taking timestamps mod 2^32 #19581

Is your feature request related to a problem? Please describe. With the current block validation rules, Bitcoin will "die" on 2106-02-07, when the unsigned 32-bit timestamp rolls over.

Describe the solution you'd like Currently, Bitcoin's timestamp protection rules work as follows:

1. The new block timestamp may not be lower than the median of the last 11 blocks'
2. The new block timestamp may not be greater than the current time plus two hours

If they would be changed to the following, the problem would be solved:

1. The new block timestamp plus k*2^32, where k is an integer, may not be lower than the median of the last 11 blocks'
2. The new block timestamp plus k*2^32, where k is an integer, may not be greater than the current time plus two hours
3. The values of k in 1 and 2 must be the same

This would cause a hardfork in 2106, which is 85.5 years from now, by which time 95% of nodes would hopefully have updated.

Describe alternatives you've considered 64-bit timestamps have been proposed. They would break compatibility with a lot of other software, and cause a hardfork before the date of timestamp overflow.

Since a hard fork is always needed, why wouldn't we just extend the block header and make it a uint64 field?

That would break compatibility with a lot of other software, and cause a hardfork before the date of timestamp overflow.

Usually the issue tracker is used to track technical issues related to the Bitcoin Core code base. Keep in mind that network-wide consensus and/or P2P changes first need to be discussed with the greater community, e.g. the bitcoin-dev mailing list. Also, they need a BIP to be implemented in Bitcoin Core and other software that connects to the bitcoin P2P network.