Can avarage block time calculated in every 2016 block be manipulated?

[CounterEntropy]

From https://en.bitcoin.it/wiki/Target

For reasons of stability and low latency in transactions, the network tries to produce one block every 10 minutes. Every 2016 blocks (which should take two weeks if this goal is kept perfectly), every Bitcoin client compares the actual time it took to generate these blocks with the two week goal and modifies the target by the percentage difference. This makes the proof-of-work problem more or less difficult. A single retarget never changes the target by more than a factor of 4 either way to prevent large changes in difficulty.

AFAIK, there is no way to verify the accuracy of a block's timestamp. So, what if a miner, mining the 2016^th block releases it with a inaccurate timestamp? Wont it indirectly affect the difficulty of the network?

p.s. Could anyone please point me to the code where Target re-calculation takes place?

[1714636614]

1714636614

[1714636614]

1714636614

[1714636614]

1714636614

[1714636614]

1714636614

[1714636614]

1714636614

[-ck]

The algorithm does not look at the timestamp at all, but when the blocks arrive.

[CounterEntropy]

The algorithm does not look at the timestamp at all, but when the blocks arrive.

Fine. That is why I requested to see the particular part of the code. Block arrival time may be different for different nodes and that is how they might work on different difficulty.

[--Encrypted--]

The algorithm does not look at the timestamp at all, but when the blocks arrive.

I would appreciate it if someone can elaborate/confirm this. as I understand it with my very limited knowledge the algorithm does look at the timestamp. but the protocol rules requires the block timestamp to not be more than two hours in the future and greater than the median timestamp of previous 11 blocks.

https://en.bitcoin.it/wiki/Block_timestamp

so a hundred blocks with fake timestamp won't even create a large effect.

[TierNolan]

The algorithm does not look at the timestamp at all, but when the blocks arrive.

Uh, it obviously has to use the timestamp, rather than when the node receives the block.  If it didn't then different nodes would compute the value differently because they received the blocks at different times. When downloading the block chain, new nodes wouldn't be able to compute it at all.

The answer to the question is that only certain timestamps are possible.

The median timestamp of the last 11 blocks is used to determine the minimum value for the timestamp.  If blocks happen every 10 minutes, then that is around 1 hour in the past.

Similarly, nodes reject blocks that are more than 2 hours into the future.  

When a miner is mining a block they have to make sure that their block is within that range.  If it is to early, it is simply invalid.  If it is to late then other nodes won't accept it.  

If a miner mined a block that was 3 hours in the future, he would have to wait an hour before broadcasting it.  By that time, some other miner would probably have found a block and so the 3 hour in the future block would be rejected.

This means that the start and end time of the 2016 window can have an error of 1-2 hours.  Since the 2016 range is around 2 weeks, this error is not that big a deal.

The system could be improved by using the median of the last 11 blocks rather than the timestamp of 1 block.  This would prevent a single block from throwing off the result by much.

[DannyHamilton]

We can do some quick math to see just how big of an effect an invalid timestamp can have:

Intended target =10 minutes per block for 2016 blocks = 20160 minutes.

Maximum allowable variation: 120 minutes

120 minutes / 20160 minutes = 0.6%

Therefore, the new difficulty will be 0.6% easier than it otherwise would have.

Since the target difficulty is intended to result in blocks occurring every 10 minute (600 seconds) on average, the new "faulty" difficulty will result in blocks occurring every:

600 seconds * 99.4% = 596.4 seconds

Which means that, at best, by using a fake timestamp on the final block of a difficulty period to manipulate the new difficulty, the "attacker" can cause the future blocks to occur on average 3.6 seconds sooner than they otherwise would have.

This new "faulty" faster average will last for the entire 2016 blocks, which means that the 2016 block difficulty period will last on average 121 minutes less than it otherwise would have.

At that point, assuming the last block has an accurate timestamp, difficulty will re-adjust to be more difficult than it otherwise would have (since the start time is 2 hours later than it should be).  The next 2016 blocks will come 3.6 seconds later than they otherwise would have.

This new "faulty" slower average will last for the entire 2016 blocks, which means that the 2016 block difficulty period will last on average 121 minutes longer than it otherwise would have.

So, by the time you get to the end of 2 difficulty periods (approximately 4 weeks), the difficulty will go back to the proper value.  During the first half of those 4 weeks blocks will have occurred a few seconds faster than usual, and during the last half they will have occurred a few seconds slower than usual, but the average across the entire 4 weeks will be correct.  There is enough variation in time between blocks that a difference of a few seconds one way or the other over a couple of weeks won't even be noticed, especially since the average across the entire 4 week period is still accurate.

[tertius993]

Would it be possible for the timestamps on the final block in consecutive periods to compound the error rather than cancelling each other out?

i.e. if a someone made a concerted effort of falsifying the timestamp on the last block in each period could they stretch the average time by a meaningful amount?

[DannyHamilton]

Would it be possible for the timestamps on the final block in consecutive periods to compound the error rather than cancelling each other out?

i.e. if a someone made a concerted effort of falsifying the timestamp on the last block in each period could they stretch the average time by a meaningful amount?

First of all, they'd have to have a LOT of hash power to be sure that they get the final block of each difficulty period.  The odds of getting that block are the same as the odds of getting any other block.  In other words, if you had 10% of the total global hash power, you would on average solve only 1 out of every 10 last blocks of difficulty periods.  If you had 25% of the total global hash power, you would on average solve only 1 out of every 4 last blocks of difficulty periods.

To have enough hash power to consistently solve the last block of a difficulty period, you'd have to have more hash power than the rest of the world combined.  If you have that, then you already have enough to pull off a 50% attack, and this "last block of difficulty period" is no longer interesting.

Now, even if you somehow were lucky enough to get the last block of 10 difficulty periods in a row, the best you could do would be to create an oscillation between blocks that are a few seconds too fast and blocks that are a few seconds too slow.

Here's an example where the "attacker" gets the last block in the period 4 periods in a row and always adds 2 hours to his timestamp:

Period 1 => Start timestamp accurate, end timestamp 120 minutes late. (new difficulty results in blocks occurring 3.6 seconds sooner)

Period 2 => Start timestamp 120 minutes late, end timestamp 120 minutes late.  (notice that you lose 120 minutes off the beginning of the period, but gain those same 120 minutes at the end of the period, therefore the total period is still accurate. As such new difficulty results in blocks occurring with an average 10 minute interval.)

Period 3 => Start timestamp 120 minutes late, end timestamp 120 minutes late.  (notice that you lose 120 minutes off the beginning of the period, but gain those same 120 minutes at the end of the period, therefore the total period is still accurate. As such new difficulty results in blocks occurring with an average 10 minute interval.)

Period 4 => Start timestamp 120 minutes late, end timestamp 120 minutes late.  (notice that you lose 120 minutes off the beginning of the period, but gain those same 120 minutes at the end of the period, therefore the total period is still accurate. As such new difficulty results in blocks occurring with an average 10 minute interval.)

Period 5 => Start timestamp 120 minutes late, end timestamp accurate. (new difficulty results in blocks occurring 3.6 seconds later)


Here's what happens if he oscillates instead:


Period 1 => Start timestamp accurate, end timestamp 120 minutes late. (new difficulty results in blocks occurring 3.6 seconds sooner)

Period 2 => Start timestamp 120 minutes late, end timestamp 60 minutes early.  (notice that you lose 120 minutes off the beginning of the period, and lose another 60 minutes at the end of the period, therefore the total period is off by 3 hours. As such new difficulty results in blocks occurring about 5.4 seconds later than they otherwise would.)

Period 3 => Start timestamp 60 minutes early, end timestamp 120 minutes late.  (notice that you gain 60 minutes off the beginning of the period, and gain another 120 minutes at the end of the period, therefore the total period is off by 3 hours. As such new difficulty results in blocks occurring about 5.4 seconds sooner than they otherwise would.)

Period 4 => Start timestamp 120 minutes late, end timestamp 60 minutes early.  (notice that you lose 120 minutes off the beginning of the period, and lose another 60 minutes at the end of the period, therefore the total period is off by 3 hours. As such new difficulty results in blocks occurring about 5.4 seconds later than they otherwise would.)

Period 5 => Start timestamp 60 minutes early, end timestamp accurate. (new difficulty results in blocks occurring about 1.8 seconds earlier)

[tertius993]

Thanks I hadn't straightened out in my head that you would always be comparing to "real" time and effectively lose the 120 minutes at the beginning of the period.

Which raises a different question - why is the acceptable timestamp such a large window? In particular why allow up to two hours into the future?

[TigerMart]

Which raises a different question - why is the acceptable timestamp such a large window? In particular why allow up to two hours into the future?

Because miners may not find a block for ~120 minutes. ~60 minutes wait is not very unusual now.

[DannyHamilton]

Thanks I hadn't straightened out in my head that you would always be comparing to "real" time and effectively lose the 120 minutes at the beginning of the period.

Which raises a different question - why is the acceptable timestamp such a large window? In particular why allow up to two hours into the future?

The timestamp is only used by the protocol for computing difficulty.

I'm not sure, but I don't think Satoshi ever explained exactly why he chose the range that he did, but it's a variation of about a half of a percent for the only calculation that it's ever used for.  Perhaps he just felt that a half percent was small enough to be lost in the variation of block times, so it wouldn't really matter.

[-ck]

My bad, sorry.