Abstract: We examine two of Bitcoin’s little-known rules, designed to stop nefarious miners from manipulating the block timestamps and achieving unfairly high mining rewards. We discuss why constants such as the two-hour MAX_FUTURE_BLOCK_TIME value may have been chosen and how this value may have particular implications for Bitcoin Cash. We conclude that Bitcoin’s time protection rules appear reasonably effective, an impressive feat, considering the lack of a functioning network when the rules were implemented.
Bitcoin’s Time Problem
One might think that time is not an important consideration for the Bitcoin network, since the blocks already have a sequential order, as each block references the hash of the previous block. Bitcoin blocks also contain transactions (inputs, outputs and values), a Merkle tree leading to the block header and the block hash itself, used for proof of work. On the surface this may seem sufficient for a transaction and consensus system. However, there is the matter of the difficulty adjustment – if too many miners join the network, the block times could become too fast, or if too many miners leave, the block times could become too slow, making the network unreliable. To resolve this problem, every two weeks the mining difficulty adjusts to aim for a target time between blocks of ten minutes. Unfortunately, in order to calculate the two-week period, the concept of time needs to be introduced to the blockchain and be part of the consensus system. Therefore blocks are required to contain a timestamp, and one can think of Bitcoin as the world’s first distributed electronic clock.
Block Timestamp Security Rules
When a Bitcoin block is produced there are essentially two times involved:
- The timestamp in the block header, put there by the miner
- The actual time the block was produced.
Of course, these two times should be pretty much the same. After all, surely the miners have reasonably accurate clocks and why would they lie about the time?
As it happens, there are some incentives for miners to lie about the time. For instance, nefarious miners could add a timestamp which is in the future. For example, if a block took 10 minutes to produce, miners could claim it took them 15 minutes, by adding a timestamp 5 minutes into the future. If this pattern of adding 5 minutes is continued throughout a two week difficulty adjustment period, it would look like the average block time was 15 minutes, when in reality it was shorter than this. The difficulty could then adjust downwards in the next period, increasing mining revenue due to faster block times. Of course, the problem with this approach is that the Bitcoin clock continues to move further and further out of line with the real time.
To resolve or mitigate the above issue, Bitcoin has two mechanisms to protect against miners manipulating the timestamp:
- Median Past Time (MPT) Rule – The timestamp must be further forwards than the median of the last eleven blocks. The median of eleven blocks implies six blocks could be re-organised and time would still not move backwards, which one can argue is reasonably consistent with the example, provided in Meni Rosenfeld’s 2012 paper, that six confirmations are necessary to decrease the probability of success below 0.1%, for an attacker with 10% of the network hashrate.
- Future Block Time Rule – The timestamp cannot be more than 2 hours in the future based on the MAX_FUTURE_BLOCK_TIME constant, relative to the median time from the node’s peers. The maximum allowed gap between the time provided by the nodes and the local system clock is 90 minutes, another safeguard. It should be noted that unlike the MPT rule above, this is not a full consensus rule. Blocks with a timestamp too far in the future are not invalid, they can become valid as time moves forwards.
Rule number one ensures that the blockchain continues to move forwards in time and rule number two ensures that the chain does not move too far forwards. These time protection rules are not perfect, for example miners could still move the timestamps forward by producing timestamps in the future, within a two week period, however the impact of this would be limited.
As the above ratio illustrates, since two hours is only a small fraction of two weeks, the impact this manipulation has on network reliability and mining profitability may be limited. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 54 seconds, in the two weeks after the difficulty adjustment. In addition to this, it is only a one-off change, as once the two-hour time shift has occurred, it cannot occur again, without first going backwards. At the same time, the miner may want to include a margin of safety before shifting forwards two hours, to reduce the risk of the block being rejected by the network.
These rules have proven reasonably effective in preventing miners from manipulating Bitcoin’s timestamps in nefarious ways, as far as we can tell.
Bitcoin Cash’s Theoretical Block Time Problems
As we first mentioned back in September 2017, Bitcoin Cash is an alternative coin which split off from Bitcoin in August 2017, the primary objective of the coin was to increase the blocksize limit. One of the concerns the Bitcoin Cash developers had at the time was that not many miners would mine Bitcoin Cash, and therefore the time gap between blocks could be too large. As a result something called the Emergency Difficulty Adjustment (EDA) was implemented to alleviate this concern. We will not go into the details here, but suffice to say this mechanism was highly complex and turned out to be fundamentally flawed. This algorithm meant that if a certain number of blocks were not found within a certain time period, the difficulty would reduce. The policy was particularly aggressive, as it meant that the longer the time gaps between blocks, the larger the downward difficulty adjustment. Miners manipulated the network by leaving large time gaps on purpose, resulting in large difficulty changes, followed by low-difficulty periods with blocks being produced at a very high frequency. The network then became unreliable.
As a result of this flaw, more Bitcoin Cash blocks were produced than expected and miner revenue increased during this period. Bitcoin Cash built a c.5,000 block lead over Bitcoin, a lead it still maintains to this day. A couple of months later, in November 2017, a fix was eventually rolled out. The EDA was removed and replaced with a new difficulty adjustment system, a more simple rolling 24-hour system. However, this is still different to Bitcoin’s two-week window system. Bitcoin Cash’s system is more dynamic and faster to adjust. While this means Bitcoin Cash may have a more volatile difficulty in the short term, the coin is faster to adjust to any changes, while any block time discrepancies in Bitcoin may take longer to correct.
Overview of Bitcoin and Bitcoin Cash’s Difficulty Adjustment Systems
Every 2 weeks
(Source: BitMEX Research)
One thing that many may have overlooked in Bitcoin Cash’s new difficulty adjustment algorithm is its interrelationship with the two-hour time protection rule. As far as we are aware, Bitcoin Cash has retained the 2 hour constant.
A two-hour period is now 8.3% of the calculation period. This is the equivalent of a reduction in the time between blocks from 10 minutes to 9 minutes and 10 seconds. This does appear to be potentially significant and could result in changes to miner profitability, if exploited. Bitcoin Cash may therefore be somewhat vulnerable to miners manipulating timestamps, or at least more vulnerable than Bitcoin.
On the other hand, although Bitcoin Cash may be more vulnerable to miner timestamp manipulation attacks than Bitcoin, any issues will be resolved faster.
The apparent vulnerability with Bitcoin Cash’s time protection rule, perhaps unexploited, illustrates how well thought out Bitcoin’s time protection rules were. As far as we know, these time protection rules existed since Bitcoin launched in 2009. When designing the system, Satoshi had to innovate at least three layers deep:
Proof of work system → Difficulty adjustment system → Robust time protection rules
While this may not seem especially ingenious to us now, we have had almost 11 years’ experience with such systems. That Satoshi had thought all this through before any such network existed is quite remarkable, in our view.