<p>Yes, the network would accept blocks that are dated up to 2h into the future. If close to or more than half the hashrate generally dated blocks two hours into the future, miners using an accurate timestamp would occasionally see their block rejected because its timestamp would not surpass the median-time passed of the last 11 blocks.</p>
<p>The attacked miners would then probably respond by also dating their blocks two hours into the future and that would be the overall end to the attack.</p>

CC BY-SA 4.0
2023-10-05T17:14:20.007Z
2023-10-05T17:14:20.007Z
Murch
<blockquote>
<p><strong>My question is whether a miner could 'postdate' the Timestamp up to 2 hours into the future, and still have the block be accepted as valid by other nodes?</strong></p>
</blockquote>
<p>In <code>validation.cpp</code> for version 23 of Bitcoin core I find</p>
<pre><code>    // Check timestamp
    if (block.GetBlockTime() &gt; nAdjustedTime + MAX_FUTURE_BLOCK_TIME)
        return state.Invalid(BlockValidationResult::BLOCK_TIME_FUTURE, &quot;time-too-new&quot;, &quot;block timestamp too far in the future&quot;);
</code></pre>
<p><code>MAX_FUTURE_BLOCK_TIME</code> is defined elsewhere as two hours (<code>2 * 60 * 60</code>)</p>
<p>So yes, &quot;valid&quot;.</p>
<p>I couldn't find anything else relevant in the code but I'm not a Bitcoin core developer so probably don't look for the right things in the right places.</p>

CC BY-SA 4.0
2023-10-05T16:11:01.167Z
2023-10-05T16:17:34.813Z
2023-10-05T16:17:34.813Z
RedGrittyBrick
<p>When a miner adds the Timestamp to a block template, it must satisfy two conditions:</p>
<ol>
<li>Timestamp must be greater than the Median Timestamp of the previous 11 blocks</li>
<li>Timestamp must be less than its local Network Adjusted Time (current time) + 2 hours</li>
</ol>
<p>My question is whether a miner could 'postdate' the Timestamp up to 2 hours into the future, and still have the block be accepted as valid by other nodes?  A similar question was asked and answered here:</p>
<p><a href="https://bitcoin.stackexchange.com/a/85621/142060">https://bitcoin.stackexchange.com/a/85621/142060</a></p>
<blockquote>
<p>If a block's timestamp is in the future, it won't be accepted [by other nodes]</p>
</blockquote>
<p>However, this answer doesn't specifically address the case of when the Timestamp is within that 2 hour window.  Isn't it true that a node would accept a 'postdated' Timestamp if it was within 2 hours of its local Network Adjusted Time?</p>
<p>If so, what are the implications of a significant percentage of miners doing this?  It seems that miners could artificially increase the trailing Median Timestamp.  Could this be used as an attack vector against other miners running the default <code>getblocktemplate</code> in Bitcoin Core? Specifically, would other miners produce invalid blocks if their Network Adjusted Time is earlier than the Median Timestamp?</p>
<p>Thank you</p>

<consensus><attack><mining-software><timestamp><getblocktemplate>
Miners setting timestamps up to 2h into the Future
sha2fiddy
# Miners setting timestamps up to 2h into the Future

(Asked by: username_0 on 2023-10-05)

When a miner adds the Timestamp to a block template, it must satisfy two conditions:

1. Timestamp must be greater than the Median Timestamp of the previous 11 blocks
2. Timestamp must be less than its local Network Adjusted Time (current time) + 2 hours

My question is whether a miner could 'postdate' the Timestamp up to 2 hours into the future, and still have the block be accepted as valid by other nodes? A similar question was asked and answered here:

<https://bitcoin.stackexchange.com/a/85621/142060>

> If a block's timestamp is in the future, it won't be accepted [by other nodes]

However, this answer doesn't specifically address the case of when the Timestamp is within that 2 hour window. Isn't it true that a node would accept a 'postdated' Timestamp if it was within 2 hours of its local Network Adjusted Time?

If so, what are the implications of a significant percentage of miners doing this? It seems that miners could artificially increase the trailing Median Timestamp. Could this be used as an attack vector against other miners running the default `getblocktemplate` in Bitcoin Core? Specifically, would other miners produce invalid blocks if their Network Adjusted Time is earlier than the Median Timestamp?

Thank you

**Tags:** consensus, attack, mining-software, timestamp, getblocktemplate


---

## 2 answers

### Answer by username_1 on 2023-10-05. Score: 1 | Accepted answer

Yes, the network would accept blocks that are dated up to 2h into the future. If close to or more than half the hashrate generally dated blocks two hours into the future, miners using an accurate timestamp would occasionally see their block rejected because its timestamp would not surpass the median-time passed of the last 11 blocks.

The attacked miners would then probably respond by also dating their blocks two hours into the future and that would be the overall end to the attack.


---

### Answer by username_2 on 2023-10-05. Score: 0

> **My question is whether a miner could 'postdate' the Timestamp up to 2 hours into the future, and still have the block be accepted as valid by other nodes?**

In `validation.cpp` for version 23 of Bitcoin core I find

```
    // Check timestamp
    if (block.GetBlockTime() > nAdjustedTime + MAX_FUTURE_BLOCK_TIME)
        return state.Invalid(BlockValidationResult::BLOCK_TIME_FUTURE, "time-too-new", "block timestamp too far in the future");

```

`MAX_FUTURE_BLOCK_TIME` is defined elsewhere as two hours (`2 * 60 * 60`)

So yes, "valid".

I couldn't find anything else relevant in the code but I'm not a Bitcoin core developer so probably don't look for the right things in the right places.


---

