Time warp attack can mine the remaining Bitcoins in 20 days? Core developers talk about timestamp security

Preface: The total amount of 21 million BTC designed by Satoshi Nakamoto is expected to be mined in about 2140 under normal mining conditions. So, is there any situation that will cause Bitcoin to be mined in advance? The answer is: Yes, but this solution is currently only theoretical. A variant of the 51% attack called the time warp attack can theoretically allow the remaining Bitcoins to be mined in 18.7 days at the fastest. However, rational miners will not choose short-term interests to kill a goose that can lay golden eggs for a long time.

This is also the topic about timestamp security that the original author Jameson Lopp wanted to discuss.

The following is the translation:

(Image from: pexels.com)

Bitcoin is often referred to as a secure timestamping service. Before Bitcoin, we never had a global record of truth with reliable timestamping, so how did this happen? It is usually due to Proof of Work (PoW) being combined into a few simple rules that miners must follow. The main functions of miners are:

1. Accept unsorted unconfirmed transactions and put them into a specific order;

2. Pack transactions into valid containers (blocks);

3. Timestamping blocks within an acceptable time frame;

This last property is what allows Bitcoin to control the release of the Bitcoin supply. Without it, Bitcoin would suffer from a process of rapid inflation whenever there was growth in hashrate. But it turns out that this property assigns quite a bit of utility to the Bitcoin protocol, and also allows people to use Bitcoin as a data anchor for other services. Because we have fairly strong guarantees that timestamps are within a given range, and we have mathematical guarantees about the amount of energy required to rewrite the blockchain history, Bitcoin provides a reliable anchor for data timestamping. But how reliable is it?

Bitcoin Timestamp Flexibility

In order for a node to consider the time field of a block header valid, it must meet two conditions:

1. The time cannot be more than 2 hours in the future, calculated from your computer's local time;

2. Greater than the median timestamp of the past 11 blocks;

The first rule makes sense, we obviously don't want anyone claiming to be from the future, and it's easy for nodes to reject such claims since we all agree on the current time (there are multiple ways to check the current time, and a very popular way for computers to sync their clocks is through the Network Time Protocol).

However, it is difficult to ensure that the time is not too far before a reasonable point. This is because we cannot assume that a node is validating blocks at any point near their initial creation time. Nodes need to be able to leave and rejoin the network for any reason or no reason. If historical blocks must be created within a few hours of the current time, nodes that are too far from the tip of the chain will start to reject historical blocks.

This is a passage from Satoshi Nakamoto’s white paper:

“Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone.”

Perhaps counter-intuitively, there is actually no rule that requires a block’s timestamp to be after the previous block’s timestamp. If you think about it, such a rule could lead to a problem: if a miner creates a block with a timestamp nearly 2 hours in the future, the next block will also have to wait a long time, and it will be difficult for other miners to self-correct the median time (MTP) of the past 11 blocks;

Also, keep in mind that while the Bitcoin network is expected to produce a block every 10 minutes, this is not really guaranteed. The interval between block births can vary from a few milliseconds to several hours. While the expected median time for the past 11 blocks should be 1 hour ago, it could be more or less;

Source: https://en.bitcoin.it/wiki/confirmation

Push Window

If you think about how adversaries would try to extend the acceptable timestamp window, it becomes clear that no adversary would be able to push timestamps more than 2 hours into the future (regardless of how much hashing power they have). However, an attacker with enough hashing power could impose some drag on the progress of “Bitcoin time” simply by creating blocks with nearly invalid timestamps within one second of the median time of the past 11 blocks;

Is there an incentive to do this? In extreme cases, a “time warp attack” could provide a short-term economic incentive, a topic we’ll discuss later. It’s less clear what incentive there would be to simply delay timestamps by a few hours. Although given that other protocols could be built on top of Bitcoin (like the Lightning Network) and could involve time locks, there could be other protocols in the future that could game the progress of timestamps on the blockchain by slowing down progress.

Hashpower Time Dragging

Since the earliest valid block time is based on the median time (MTP) of the past 11 blocks, a hostile miner would need to generate a large number of blocks in order to cause any noticeable resistance on the MTP.

Let’s assume a situation where all miners are roughly synchronized via the MTP, but there is a hostile miner who is trying to drag the MTP past the past 11 blocks as much as possible.

One thing is very clear: Satoshi Nakamoto’s decision was to use the median timestamp of the past 11 blocks, rather than the average, because the average is easier to manipulate . Another way to think about “median time in the past” is that if all timestamps are in order, then it basically means the timestamp of the 6th most recent block. If not, the algorithm will just reorder them. Therefore, if you want to have a non-negligible impact on this value, you need to solve 6 of the past 11 blocks. In order to sustain this attack, you need to control 55% of the hashrate of the entire network, at which point a major assumption of Bitcoin’s thermodynamic security is violated. But if miners are extremely lucky, they can sometimes do this even with a lower hashrate.

How hard is it to find 6 out of 11 blocks? Well, the chance of a given miner solving the next block is roughly the same as their percentage of the total network hashrate, so if you only have 1% of the hashrate (which is still an equally large miner), then your chance of finding 6 out of any 11 adjacent blocks = (0.01⁶*0.99⁵)*(11!/(5!*6!)) is about 1 in 2 billion. If you maintain 1% of the hashrate, your expected time to find 6 out of 11 blocks is over 43,000 years.

A more general formula for the expected waiting time to successfully complete a time-drag attack is:

(1 / (462 * (% hashrate⁶ * (1- % hashrate)⁵))) / 144 blocks/day = # days

As we can see, for an attacker to carry out this type of attack on any meaningful timescale, they would need a reasonably sized mining pool with at least 10% of the network hashrate;

The biggest drag

However, in order to create maximum resistance on the median time (MTP), miners need to solve 6 blocks in a row. If 6 of the past 11 blocks are not all in order, the gap caused by other miners will force the hostile miner to set the timestamp of their blocks to be more than one second apart from each other, because the MTP of each block will jump forward significantly (honest miners will set more accurate timestamps on their blocks).

How difficult is it to solve 6 blocks in a row? If we again assume that a single miner has 1% of the network’s hashrate, then the probability of any given 6 consecutive blocks is 0.01⁶, or about 1 in a trillion. If you maintain 1% of the network’s hashrate, then the expected time to find 6 consecutive blocks out of 11 blocks would be close to 2 million years.

A more general formula for the expected waiting time to successfully complete a time-drag attack is:

(1 / % hashrate⁶ ) / 144 blocks/day = # days

This attack is much harder to pull off and needs to happen in a reasonable amount of time, so miners would need to have 20% or 30% of the network’s hashrate. As you can imagine, this happens rarely, but when it does, people will notice. The last time this happened in Bitcoin’s history was in July 2014, when the GHash mining pool had over 40% of the hashrate for a period of time, and even over 51% for a short period of time. If you have 50% of the hashrate, the probability that you will find 6 consecutive blocks is 0.5⁶ (1 in 64). If you maintain 50% of the hashrate, you can expect to find 6 consecutive blocks every 12 hours.

Obviously, without a majority of hashrate, you are unlikely to be able to drag Bitcoin's median time over long periods of time, but you can drag it up to a few hours over short periods of time (1 block or so) with luck and patience. If you assume that other miners are reasonably accurate with their timestamps, then the median time in the past should be about 1 hour ago (although it could be a few hours more due to block changes being found). If you can create 6 blocks with timestamps from 1 hour ago plus 1 second, 2 seconds, 3 seconds, etc., then at the 6th block, the MTP would be about 2 hours ago. If we assume an extreme condition of 1 hour between blocks, then the MTP would be 6 hours ago.

By having reasonable flexibility in block timestamps and then taking the median time of recent blocks, we end up with an algorithm that is very hard to game, but not so brittle as to adversely affect miners that are somewhat out of sync with real time.

Time Warp Attack

What happens if an attacker has over 50% of the hashrate and they want to slow down the passage of Bitcoin time? They can do something very nasty. Such a hostile miner can push each new block by more than 1 second to prevent timestamping. If they do this for long enough so that the creation of the previous 2016 blocks seems to have taken more than 2 weeks, they can use retargeting logic to reduce the mining difficulty by 75% every 2016 blocks. Eventually, with the difficulty low enough, they can mint as many blocks as they want in a given time period, thereby earning more mining rewards than expected. An optimized timewarp attack could mine all remaining Bitcoins in 18.7 days . In fact, we have seen similar behavior on Bitcoin's testnet3, which was caused by coincidences of retargeting difficulty (which once produced 16,000 blocks in a single day), and now has mined 1,482,878 blocks after 8 years of history, about 350% of the expected emission.

Time warp attacks are not new. They were first performed in 2011 against a coin called “Geist Geld” and were considered by the community to be a variation of a 51% attack.

In 2014, an altcoin called Whitecoin was also hit by a time warp attack.

In 2018, the privacy coin Verge was also attacked in this way, and 6 weeks later, it was attacked again!

Generally speaking, cryptocurrencies with a small amount of hashrate for a given type of hardware (ASICs or GPUs) are susceptible to timewarp attacks because they are inherently vulnerable to 51% attacks.

Interestingly, while time warp is often referred to as an attack because it causes unexpected behavior in the system, some have demonstrated that it can be exploited for potential intended uses. In 2015, Vitalik Buterin described a method to increase on-chain capacity by speeding up blocks through a soft fork. In 2018, Bitcoin developer Mark Friedenbach proposed a proposal to exploit this unintended behavior to add new features to Bitcoin. In his "Forward Blocks" proposal, Mark stated that his method could expand on-chain transaction volume to 3,584 times the current level.

However, such a proposal is controversial and would force anyone who builds a system that relies on Bitcoin block header timestamps to look elsewhere for that data. It would also be easy to block such a change, as Greg Maxwell explained on the Bitcoin developer mailing list:

“It can be fixed via a soft fork that further restricts timestamps, and there are several proposals along these lines.”

Summarize

The security of Bitcoin timestamps, and the simple rules that limit the window of acceptable timestamps, have withstood the test of 10 years in an adversarial environment despite known weaknesses. We know that a group of miners with 51% of the hashing power could, at least in the short term, cause damage to the network, but this has never happened, most likely because the incentives are not right for miners to do so. Rational miners will not choose short-term interests over killing a goose that lays golden eggs in the long term.