# Question about Bitcoin's Median Time Past

I was currently reading the book Mastering Bitcoin written by Andreas and was pretty confused about the concept called Median Time Past. Hopefully I can get some of your advice.

From my understanding, when creating a new block, its header time must satisfy two primary conditions:

1. It must be greater than the median time of the past 11 blocks
2. The time offset between itself and network adjusted time must be less than 2 hours.

This is what I understand about condition #1, considering 11 blocks with their given header time :

#1 - created at time 1

#2 - created at time 2

...

#11 - created at time 11

When a block #12 is created, based on above rule it is possible to set its header time to 7.

If this happens continually, isn't it weird to have a block's header time going up and down like that ?

Thank you.

It is a bit weird, but it is simply not possible to have everyone's clocks be in sync, and so there must be leeway for a block to have a timestamp earlier than its predecessor. If my clock is a few seconds behind your clock, and I find a block 1 second immediately after yours, my block should not be rejected just because my clock is out of sync with yours. One of the primary purposes of the blockchain is to agree on a "time" (in the form of block height) when clocks cannot necessarily be in sync.

The MTP rule puts a lower bound on the timestamp of the next block. It is guaranteed to always move forward so it allows for time based locktime to work.

• I understood that the purpose of MTP is to help reach a consensus on time, but I am still not able to imagine an example of it. Can you give me an example for a new block after 11 blocks with their specific time? Jun 2, 2022 at 10:05
• Could you explain why it would be necessary to sync the clocks here? If I find a block 1 second immediately after yours, then either I haven't seen your block (so one of them gets orphaned and the time difference doesn't matter) or I have seen your block and could easily adapt my blocks time to come after yours. Am I missing something here? Jun 2, 2022 at 12:19
• @MarcelKrüger: The timestamp on my block may also be incorrect, either because my clock is wrong or because I am trying to cause trouble. Say I found my block at actual time 9:00, but used 9:45 as the timestamp. Now you find the next block at 9:07. Under the current rule, you can use 9:07 as the timestamp and get things back on track. If timestamps were required to increase monotonically, you'd have to use 9:46 and the error would persist. Jun 2, 2022 at 12:40
• @JohnPham Suppose you have a sequence of blocks with the times: 1, 2, 3, 2, 5, 6, 7, 4, 8, 6, 9. The median of this is 5, so the next block must have a timestamp of 6 or greater.
– Ava Chow
Jun 2, 2022 at 14:57
• @AndrewChow so supposed that the next block always have header time = MTP + 1, block #12 -> #16 will be [7, 8, 5, 9, 7, 10]. Isn't this conflict with the property that <MTP will be monotonically increasing>? Jun 3, 2022 at 2:39

Because clock of each node can be different with network adjusted time so the network must have a time gap to accept the block timestamp. In your question, your timestamp definitely could be in the past, but must have a limit of late so the network is not be effected to heavy. And this limit is the median time of the past 11 blocks. It implies your timestamp can be maximum in the block 7 in your example. If your timestamp make your block in the 6th, your block will invalid. Although it's weird, but it's necessary for the safety of the netowrk :D

• Thanks for your answer man, really took me time to understand this timing concept. Oct 1, 2022 at 15:18