MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Sat, 19 Sep 2020 12:36:47 +0000
From: yanmaani@cock.li
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <42c7e76c023b403a9e99d29a1836b53e@cock.li>
User-Agent: Roundcube Webmail/1.3.10
Subject: [bitcoin-dev] Suggestion: Solve year 2106 problem by taking
	timestamps mod 2^32
Precedence: list

Currently, Bitcoin's timestamp rules are as follows:

1. The block timestamp may not be lower than the median of the last 11 
blocks'
2. The block timestamp may not be greater than the current time plus two 
hours
3. The block timestamp may not be greater than 2^32 (Sun, 07 Feb 2106 
06:28:16 +0000)

Thus, Bitcoin will "die" on or about 2106-02-07, when there is no 
timestamp below 2^32 that exceeds the median of the last 11 blocks.

If the rules were changed to the following, this problem would be 
solved:

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

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

Another proposed solution is 64-bit timestamps. They would break 
compatibility with other software that has specific expectations of 
header fields, like ASICs' firmware. They would also cause a hardfork 
before the date of timestamp overflow. I thus believe them to be a less 
appropriate solution.

What do you think of this idea? Is it worth a BIP?