The Bitcoin Protocol (consensus guidelines) has two related guidelines for the timestamps in block headers:
- A node won’t settle for a block whose timestamp is greater than two hours sooner or later.
- A node won’t settle for a block until 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 will principally give them only a small lower within the problem, 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 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, that means that after miners create the slightly-future-time block on the finish of the problem interval, they needn’t 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 appear like:
[-27, -27, -27, -27, -27, -27, -27, -27, -27, -27, 0]
So miners can proceed holding timestamps far prior to now and repeat the assault, reducing problem each interval till the purpose the place it takes them lower than 2,016 seconds to provide 2,016 blocks, at which level they can not 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 important query was how can this assault work with out collusion by a majority of miners. Now that you have seen how the assault works with all miners taking part, it ought to be clear than choosing the median time can enable an attacking miner who’s fortunate sufficient to search 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]
If you happen to type these numbers to search out the median, it is -27 although 5/11ths (45%) of the hashrate is mining precisely. However wait, would 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 receive a bonus over different miners utilizing a egocentric mining assault, or the miner might merely threaten to aim to make stale (“orphan”) different miners blocks who’ve correct time stamps, inflicting these trustworthy miners to earn much less revenue.
I personally do not contemplate the assault significantly doubtless on Bitcoin as a result of it is gradual to execute and publicly apparent, nevertheless it’s one thing protocol designers do want to remember for after they change parameters, as these modifications might make the assault simpler to execute.
