The Bitcoin Protocol (consensus guidelines) has two related guidelines for the timestamps in block headers:
- A node is not going to settle for a block whose timestamp is greater than two hours sooner or later.
- A node is not going to settle for a block until it has a timestamp better than the median of the earlier 11 blocks. In Bitcoin, we name this Median-Time-Previous (MTP).
As you point out in your query, issue modifications are calculated primarily based on the instances of the primary and final blocks in a 2,016-block issue interval.
Given the above guidelines, if all miners agreed, they might merely increment the clock the minimal quantity of 1 second MTP for the primary 2,015 blocks after which set the time to 2 hours sooner or later. That will mainly give them only a small lower within the issue, however take into consideration what occurs to the MTP after they add that final slightly-future datapoint: the precise median would not change a lot in any respect. Precise time stamps are in seconds, however here is a set of 11 timestamps in days delta from current time:
[-13, -13, -13, -13, -13, -13, -13, -13, -13, -13, 0]
The median of the above is -13, that means that after miners create the slightly-future-time block on the finish of the problem interval, they need not transfer their timestamps ahead greater than the minimal one second—so the following issue interval begins out -13 days.
On the finish of the following issue interval, miners once more transfer the timestamp ahead so far as potential, so the protocol thinks it took 28 days to mine the blocks—half the anticipated speed—and so decreases the problem by about half. Now the values used for MTP appear like:
[-27, -27, -27, -27, -27, -27, -27, -27, -27, -27, 0]
So miners can proceed retaining timestamps far prior to now and repeat the assault, reducing issue each interval till the purpose the place it takes them lower than 2,016 seconds to supply 2,016 blocks, at which level they cannot decrease issue any additional as a result of the MTP perform requires time improve by a minimal of 1 second over the median each block.
Now, your predominant query was how can this assault work with out collusion by a majority of miners. Now that you’ve got seen how the assault works with all miners taking part, it needs to be clear than deciding on the median time can permit an attacking miner who’s fortunate sufficient to seek out blocks reliably to stop median time from leaping ahead to an sincere worth. For instance, think about these are the instances of the earlier 11 blocks, in block chain sequence:
[-27, 0, -27, 0, -27, 0, -27, 0, -27, 0, -27]
If you happen to kind these numbers to seek out the median, it is -27 though 5/11ths (45%) of the hashrate is mining precisely. However wait, would not that imply the attacking miner has 55% of the hashrate? Possibly not, for a big miner with about 30% or extra of the hashrate may receive a bonus over different miners utilizing a egocentric mining assault, or the miner may merely threaten to try to make stale (“orphan”) different miners blocks who’ve correct time stamps, inflicting these sincere miners to earn much less earnings.
I personally do not take into account the assault significantly seemingly on Bitcoin as a result of it is sluggish to execute and publicly apparent, but it surely’s one thing protocol designers do want to remember for after they change parameters, as these modifications may make the assault simpler to execute.
