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 except it has a timestamp higher than the median of the earlier 11 blocks. In Bitcoin, we name this Median-Time-Previous (MTP).
As you point out in your query, problem modifications are calculated primarily based on the instances of the primary and final blocks in a 2,016-block problem 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 may mainly give them only a small lower within the problem, however take into consideration what occurs to the MTP once they add that final slightly-future datapoint: the precise median does not change a lot in any respect. Precise time stamps are in seconds, however this 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, which 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 problem interval begins out -13 days.
On the finish of the following problem interval, miners once more transfer the timestamp ahead so far as doable, 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 seem like:
[-27, -27, -27, -27, -27, -27, -27, -27, -27, -27, 0]
So miners can proceed protecting timestamps far up to now and repeat the assault, decreasing problem 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 problem 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 principal 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 collaborating, it must be clear than deciding on the median time can enable an attacking miner who’s fortunate sufficient to seek out blocks reliably to forestall median time from leaping ahead to an trustworthy 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]
In case you kind these numbers to seek out the median, it is -27 though 5/11ths (45%) of the hashrate is mining precisely. However wait, does not that imply the attacking miner has 55% of the hashrate? Perhaps not, for a big miner with about 30% or extra of the hashrate might get hold of a bonus over different miners utilizing a egocentric mining assault, or the miner might merely threaten to try to make stale (“orphan”) different miners blocks who’ve correct time stamps, inflicting these trustworthy miners to earn much less earnings.
I personally do not think about the assault notably doubtless on Bitcoin as a result of it is gradual to execute and publicly apparent, but it surely’s one thing protocol designers do want to bear in mind for once they change parameters, as these modifications might make the assault simpler to execute.
