The limit has existed since the origin of the network and will be reached on February 7, 2106, according to Morel.
Possible solutions require a hard fork, which involves reaching consensus in the community.
Bitcoin would stop on February 7, 2106 at 06:28:15 UTC if the protocol is not modified before. This was explained by Loïc Morel, a bitcoiner educator and writer, in a publication on
Morel pointed out that each Bitcoin block contains a timestamp (a record of the exact moment it was mined) that serves a coordination function and allows users to network nodes verify the chronological order of the blocks and adjust the mining difficulty every two weeks. These marks are stored in an unsigned 32-bit field, which measures the seconds since January 1, 1970, a standard system in computing known as time. Unix.
The problem, according to Morel, is that the 32-bit field has a mathematical ceiling, since the maximum value it can store is 4,294,967,295 seconds, equivalent to February 7, 2106.
Once 4,294,967,295 seconds are reached, the counter cannot continue to increase. Morel compares it to the odometer of an old car that returns to zero after reaching its limit, and the problem is not that the car breaks down, but that the counter no longer reflects reality.
Why is this paralyzing Bitcoin?
Morel details that the protocol imposes two rules on timestamp of each block to consider it valid:
The first rule states that the timestamp of the new block must be greater than the median of the previous 11 blocks, a value known as the Median Past Time (MTP).
The second rule requires that the timestamp not exceed the network median time plus two hours, to prevent miners from manipulating the clock into the future. The problem occurs when the MTP reaches its maximum value: at that point, any new timestamp would necessarily be equal to or lower than that ceiling, which violates the first rule, which requires it to be strictly higher. There is no valid number possible.
According to Morel’s analysis, the nodes would reject any new blocks proposed, because no one could fulfill both rules at the same time, and the chain would stop completely.
Two possible solutions, the same obstacle
Morel describes two technical paths to avoid that scenario. The first is to expand the timestamp field from 32 to 64 bits, which would extend the limit to approximately the year 585 billion. It is the cleanest solution, says the writer, but requires all nodes in the network to update simultaneously.
The second option is called BitBlendbased on an idea by developer Pieter Wuille, explains Morel. It keeps the 32 bits in the block header but interprets them as visible part of a 64-bit number.
When the timestamp drops sharply relative to the MTP (a sign that the counter has turned over), the nodes detect the overflow and automatically compensate. This would allow for a progressive upgrade: nodes that do not migrate immediately would follow the correct chain until the first overflow of 2106. Although it offers some temporary backward compatibility, Morel clarifies that it is still technically a hard fork.
In Bitcoin’s history, coordinating that type of exchange has proven politically complex, requiring the agreement of developers, miners, and node operators. According to Morel, the technical corrective is simple. The real challenge is governance: “We have 80 years left to act,” he concludes.