<p>As per <a href="https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki" rel="nofollow noreferrer">BIP 9</a>, the transition to FAILED takes precendence. Which means that the feature will not be activated via BIP09.
The relevant part of the code.</p>

<p><code>case STARTED: 
            if (GetMedianTimePast(block.parent) &gt;= timeout) {
                return FAILED;
            }
            int count = 0;
            walk = block;
            for (i = 0; i &lt; 2016; i++) {
...</code></p>

CC BY-SA 3.0
2017-05-30T04:04:59.783Z
Well, here's the weird thing, can you just mine with timestamps that are on time T-1? GetMedianTimePast is the average of the last 10. Does it check that it's actually near the time the blocks got relayed?
Jimmy Song
CC BY-SA 3.0
2017-05-30T04:16:16.370Z
From bitcoin Wiki:
A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. As a result, block timestamps are not exactly accurate, and they do not even need to be in order. Block times are accurate only to within an hour or two. 
The difference is  about 2 hours.
sanket1729
CC BY-SA 3.0
2017-05-30T03:25:20.663Z
2017-05-30T03:25:20.663Z
sanket1729
<p>Suppose a BIP9 feature is set to expire on day T. Suppose further that the retargeting period before T actually ends on day T+5, but the retargeting period (2016 blocks) actually signals for the BIP9 feature 95%+. Does the feature get activated or not?</p>

<p>I ask as this is a realistic scenario should BIP148 gain traction.</p>

<segregated-witness><bip9-version-bits>
How does BIP9 handle expiration dates over retargeting periods?
Jimmy Song
# How does BIP9 handle expiration dates over retargeting periods?

(Asked by: username_0 on 2017-05-30)

Suppose a BIP9 feature is set to expire on day T. Suppose further that the retargeting period before T actually ends on day T+5, but the retargeting period (2016 blocks) actually signals for the BIP9 feature 95%+. Does the feature get activated or not?

I ask as this is a realistic scenario should BIP148 gain traction.

**Tags:** segregated-witness, bip9-version-bits


---

## 1 answers

### Answer by username_1 on 2017-05-30. Score: 3 | Accepted answer

As per [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki), the transition to FAILED takes precendence. Which means that the feature will not be activated via BIP09.
The relevant part of the code.

`case STARTED:
if (GetMedianTimePast(block.parent) >= timeout) {
return FAILED;
}
int count = 0;
walk = block;
for (i = 0; i < 2016; i++) {
...`

> **Comments:**
> **username_0**: Well, here's the weird thing, can you just mine with timestamps that are on time T-1? GetMedianTimePast is the average of the last 10. Does it check that it's actually near the time the blocks got relayed?  
> **username_1**: From bitcoin Wiki: A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you. As a result, block timestamps are not exactly accurate, and they do not even need to be in order. Block times are accurate only to within an hour or two.  The difference is  about 2 hours.  

---

