<p>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</p>

CC BY-SA 4.0
2022-10-01T15:18:53.777Z
Thanks for your answer man, really took me time to understand this timing concept.
John Pham
CC BY-SA 4.0
2022-09-30T14:45:40.913Z
2022-09-30T14:45:40.913Z
Thái Hồ Vĩnh
<p>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 &quot;time&quot; (in the form of block height) when clocks cannot necessarily be in sync.</p>
<p>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.</p>

CC BY-SA 4.0
2023-02-19T03:15:33.597Z
Are there any blocks in the chain that violate that rule?
Felix Weis
CC BY-SA 4.0
2022-06-02T10:05:21.697Z
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?
John Pham
CC BY-SA 4.0
2022-06-02T12:19:25.297Z
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?
Marcel Krüger
CC BY-SA 4.0
2022-06-02T12:40:04.410Z
@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.
Nate Eldredge
CC BY-SA 4.0
2022-06-02T14:57:04.080Z
@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
CC BY-SA 4.0
2022-06-03T02:39:42.800Z
@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>?
John Pham
CC BY-SA 4.0
2022-06-03T03:48:28.680Z
@JohnPham No, MTP is the **median**, not just taking the timestamp of 6 blocks back. To be clear, in my example, the times are timestamps in the blocks, not their MTP. By taking the median, the order of the blocks does not matter, and so long as the timestamp is greater than the median, the MTP will monotonically increase.
Ava Chow
CC BY-SA 4.0
2022-06-03T03:56:41.833Z
Ahh I see, I always thought that *median* means taking the middle value without sorting the array. Thanks for your explanation man.
John Pham
CC BY-SA 4.0
2022-06-02T04:37:21.803Z
2022-06-02T04:37:21.803Z
Ava Chow
<p>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.</p>
<p>From my understanding, when creating a new block, its header time must satisfy two primary conditions:</p>
<ol>
<li>It must be greater than the median time of the past 11 blocks</li>
<li>The time offset between itself and network adjusted time must be less than 2 hours.</li>
</ol>
<p>This is what I understand about condition #1,  considering 11 blocks with their given header time :</p>
<p>#1 - created at time 1</p>
<p>#2 - created at time 2</p>
<p>...</p>
<p>#11 - created at time 11</p>
<p>When a block #12 is created, based on above rule it is possible to set its header time to 7.</p>
<p>If this happens continually, isn't it weird to have a block's header time going up and down like that ?</p>
<p>Thank you.</p>

<timestamp><locktime>
Question about Bitcoin's Median Time Past
John Pham
# Question about Bitcoin's Median Time Past

(Asked by: username_0 on 2022-06-02)

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.

**Tags:** timestamp, locktime


---

## 2 answers

### Answer by username_2 on 2022-06-02. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_4**: 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?  
> **username_5**: @username_4: 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.  
> **username_2**: @username_0 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.  
> **username_0**: @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>?  
> **username_2**: @username_0 No, MTP is the **median**, not just taking the timestamp of 6 blocks back. To be clear, in my example, the times are timestamps in the blocks, not their MTP. By taking the median, the order of the blocks does not matter, and so long as the timestamp is greater than the median, the MTP will monotonically increase.  
> **username_0**: Ahh I see, I always thought that *median* means taking the middle value without sorting the array. Thanks for your explanation man.  
> **username_3**: Are there any blocks in the chain that violate that rule?  

---

### Answer by username_1 on 2022-09-30. Score: 1

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

> **Comments:**
> **username_0**: Thanks for your answer man, really took me time to understand this timing concept.  

---

