user132110: 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:

It must be greater than the median time of the past 11 blocks
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.

user136918: 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

user48884: 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.

132110: <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>
 136918: <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>
 48884: <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>
