# Why does the median-past time average the last 11 block timestamps and not the last 12?

As described in BIP-113. Wouldn't the last 12 blocks bring us closer to a one-hour offset (ie 120min, midpoint 60)?

BIP 113's goal is not to aim for a specific offset.

Its goal is guaranteeing monotonicity (treating every block's timestamp as strictly larger than the timestamp of each of its ancestors). It does this by leveraging the existing consensus rule which states that the median of the timestamp of a block has to be strictly larger than the median of its 11 predecessors.

As to why the number 11 eleven was chosen in that existing consensus rule, we don't know. It was chosen by Bitcoin's creator.

• As I also answered my question, the problem was specifically around the one-hour offset. I confused median with average, as I'm still getting used with maths in English. But thank you for your answer, it provided clear and helpful info! Commented Jun 20, 2018 at 22:46
• Median or average is not relevant. If the existing consensus rule would have been average, BIP113 would have chosen the same. Commented Jun 20, 2018 at 23:12
• I agree, that stands for BIP113. However, we cannot know for sure that they would have selected the same number, ie 11, had the Bitcoin creator chosen the average not the median. Commented Jun 21, 2018 at 8:51

It is a median, not an average, thus it selects the 6th block's timestamp after sorting.

If you're a non-native English speaker, international maths heuristics can be quite tricky. Double-check on the Internet before translating into your head.

For posterity, I want to share what I now believe to be the reason why 11-blocks was chosen for the `median_timestamp` calculation.

By calculating a median timestamp value of the previous 11 blocks, we derive a best-effort assumption of when a block was mined, 6 blocks prior, while accounting for the fact that the `timestamp` field is inexact.

This is to say that by enforcing that the `timestamp` of the current block must be greater than the `median_timestamp` (the 'assumed actual timestamp') of the trailing 6th-prior block, we allow a 1-hour fluctuation (on average) to the value that a miner attaches to the current block.

Simply:

6 blocks ago = 1 hour ago (on average) = a reasonable round number in wall-time to allow for fluctuation, when assigning the current block's timestamp

thus it selects the 6th block's timestamp after sorting

I believe this is what Paul meant here ^^^ but hopefully this detailed explanation is helpful to others.