3

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

Paul Razvan Berg
  • 239
  • 1
  • 14

3 Answers3

5

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.

Pieter Wuille
  • 105,497
  • 9
  • 194
  • 308
  • 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!

     – Paul Razvan Berg Jun 20 '18 at 22:46
  • Median or average is not relevant. If the existing consensus rule would have been average, BIP113 would have chosen the same. – Pieter Wuille Jun 20 '18 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. – Paul Razvan Berg Jun 21 '18 at 08:51
3

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.

Paul Razvan Berg
  • 239
  • 1
  • 14
2

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.

sha2fiddy
  • 65
  • 6