Miners setting timestamps up to 2h into the Future

Question

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

Answer 1

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 2

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.