If you are interested in computer science, you may have already heard of the famous bug of the year 2038, which will affect all computer systems using the Unix timestamp stored as a 32-bit signed integer. On Bitcoin, this bug will not concern us. However, Bitcoin time stamps also have a maximum value that cannot be exceeded. This threshold will be reached on February 7, 2016.
So will the year 2106 spell the death knell for Bitcoin? In this article, we take stock of this relatively unknown event with you.
What is the timestamp on Bitcoin?
On the Bitcoin protocol, a blockchain is used to avoid double spending. Each transaction is placed in a block with a time frame. In other words, we put an hour and a day on each block in order to be able to put them in chronological order. This time frame is what we call a “timestamp.”
Thanks to this mechanism, when a node receives a new Bitcoin transaction waiting for confirmation, it can verify that, in the past, those same Bitcoins were not already spent. In this way, we avoid double spending on the system, without making it rely on a central authority.
The timestamp is in the header of each block. It is a 32-bit integer that is based on UNIX time. To determine this time frame, we count the number of seconds that have passed since January 1, 1970, and that gives us a whole number. For example, when I am writing this article, 1,693,498,694 seconds have passed since 1970. All I need to do is convert this integer to binary to get my timestamp. In this case, this would give us: 01100101110001100100100101011111110. This is how you timestamp blocks on Bitcoin.
What is wrong with the year 2106 on Bitcoin?
The timestamp on Bitcoin is done on unsigned 32-bit integers. This means that you can put 32 zeros or one in a row to represent time, but not one more. So there is a limit on the interpretation of time within Bitcoin. The maximum value that can be used is as follows: 1111111111111111111111111111111111. In decimal value, this gives us 4,294,967,295 seconds, and this time corresponds to the date February 7, 2106.
After this date is exceeded, the timestamp will overflow and it will reset to zero. Computer systems using this format will interpret the current date as January 1, 1970, when in reality it will be 2106.
To better understand this phenomenon, let's draw an analogy. Some old car odometers are limited to 6 digits. As a result, the maximum value that can be displayed is 999,999 km. Once this limit is reached, the counter goes back to zero and starts counting again from the beginning. However, the kilometers already covered by the car have taken place. Therefore, there is a difference between the interpreted value and the real value, because of the number of digits that can be displayed. For the timestamp on Bitcoin, it's exactly the same principle.
If nothing is changed in the Bitcoin protocol, this discrepancy between the interpretation of the timestamp and the reality will mean that no new blocks can be published. Indeed, there are two restrictions on the timestamp of a block in order for it to be accepted by the nodes:
It must be greater than the median time of the previous 11 blocks;
and it should be less than the median of the node timestamps plus 2 hours.
Once the 32-bit timestamp reaches its maximum value on February 7, 2106, you can still publish a maximum of 6 blocks (this is due to the fact that the low limit is a median). Then, the blockchain should stop and no more transactions could be confirmed.
Fortunately, there are many solutions to be able to bypass this date and thus prevent possible repercussions on Bitcoin.
📌 The difference between signed and unsigned 32-bit integers is in the number of bits available. The unsigned make full use of 32 bits (that's what we have on Bitcoin), while the signed reserve one bit for the sign, leaving 31 bits to represent a positive number (this is what is used on systems affected by the 2038 bug).
Don't worry, we have more than 80 years left to solve this small problem! To do this, several solutions exist. The one that comes most naturally would be to change the size of the integer used to write down the timestamp on Bitcoin. We could thus use 64-bit integers, which would allow us to push the time limit to several hundred billion years in the future.
Another solution would be to keep a 32-bit timestamp, but interpreted as a 64-bit integer. Only the last 32 bits of the integer would be noted in the block header, but at each overflow, the nodes would add 2^32 to the noted value to get the real value. Overflows could be detected by nodes as soon as the 32-bit timestamp drops sharply compared to previous blocks.
However, these two solutions are hard forks. The Bitcoin community will have to agree in the next 80 years to foresee this change, before the fateful date of February 7, 2016 arrives.
In Bitcoin block headers, the timestamp is an unsigned 32-bit integer. It allows you to associate a time marker with the block. In this way, we can determine the chronological order of transactions, and thus avoid the double spending of bitcoin coins.
This timestamp will reach its maximum value on February 7, 2106 and will cause the Bitcoin blockchain to stop if nothing is done. Fortunately, this bug is not only very remote, but also very easy to fix. Full node operators will have to update the protocol via a hard fork before this deadline. The objective will be either to change the interpretation of the integer timestamp, or to extend its size to 64 bits, thus allowing Bitcoin to function for a few hundred billion more years.
