<p>Bitcoin Core will generally connect to at least 10 outbound peers (8 regular, 2 blocks-only). It will ask all of the peers for their chaintips and then start synchronizing the header chain for the chaintip with the most work after choosing a single header sync peer. Only when it has acquired all block headers of the peer and validated them to the extent possible, will it start downloading blocks and advancing its active chaintip. As long as one of our node’s peers is honest and caught up, we’d already be on our way to the actual chaintip.</p>
<p>A block whose timestamp is older than the median of the 11 preceding blocks would simply be rejected at the header sync stage, so we must assume that the attacker is serving a blockchain that is a week old.</p>
<p>If our node were to be eclipsed and all of its peers were offering only a chaintip that is older than a week, our node would synchronize with that chaintip. Our node <strong>would remain in &quot;initialblockdownload&quot; state</strong>, as it only disables IBD-mode once the timestamp of the node’s active chaintip is no more than 24 hours in the past of its own system time. This would e.g. cause the wallet GUI to display a warning that the node is not caught up. The node would also start trying to make additional connections due to not making progress. If it finds any honest peer, it will continue synchronizing towards the actual best chain. If the eclipse attack persists, it will stall, but remain in IBD mode.</p>
<p>So, the chaintip would be considered valid, but the node would not consider itself caught up to the network.</p>

CC BY-SA 4.0
2024-07-17T00:16:18.220Z
2024-07-18T21:16:31.210Z
2024-07-18T21:16:31.210Z
Murch
<p>I recently encountered an assertion about this and I have been trying to get to the bottom of it. It's well-known that Bitcoin blocks have timestamps and that there are certain requirements they need to satisfy for a block to be considered valid, namely (as per <a href="https://learnmeabitcoin.com/technical/block/time/" rel="nofollow noreferrer">this source</a>) a block timestamp needs to be later than the median of the last 11 blocks, and not 2 hours in the future relative to a measure of the current time.</p>
<p>My question is not about block validity, but about practical safeguards that a client might use to detect malfeasance. Is there not any safeguard in place in typical bitcoin clients that prevents a relatively old block, say one week old, from being accepted by a bitcoin client as the most recent block and the current accepted state of the chain? It seems like this would be a good safeguard - it is very unlikely that the most recent block would ever truly be this old, and preventing a client from accepting a block such as this seems like it might prevent an attack from an adversary trying to pass off an old state of the chain as current.</p>

CC BY-SA 4.0
2024-07-16T22:33:04.803Z
It’s not quite clear to me, how we would end up in a scenario where a block with a week old timestamp looks like the best chaintip to us. Do we only have a single peer or are eclipsed in your scenario? Or is there a network split on-going that split off all hashrate from our section of the internet? Does [How does block synchronization work in Bitcoin Core today?](https://bitcoin.stackexchange.com/q/121292/5406) answer your question?
Murch
CC BY-SA 4.0
2024-07-19T12:20:45.187Z
Thanks for your answer. Eclipsing is perhaps one way I imagined this might happen, but the context for why I am asking is related to [this paper](https://arxiv.org/abs/2403.08023) that a colleague and I wrote about quantum attacks on PoW and how certain versions of the attack could result in apparently old but high-difficulty chain tips.
Bolton Bailey
<bitcoin-core><timestamp>
Can a block more than a week old be considered a valid chain tip?
Bolton Bailey
# Can a block more than a week old be considered a valid chain tip?

(Asked by: username_0 on 2024-07-16)

I recently encountered an assertion about this and I have been trying to get to the bottom of it. It's well-known that Bitcoin blocks have timestamps and that there are certain requirements they need to satisfy for a block to be considered valid, namely (as per [this source](https://learnmeabitcoin.com/technical/block/time/)) a block timestamp needs to be later than the median of the last 11 blocks, and not 2 hours in the future relative to a measure of the current time.

My question is not about block validity, but about practical safeguards that a client might use to detect malfeasance. Is there not any safeguard in place in typical bitcoin clients that prevents a relatively old block, say one week old, from being accepted by a bitcoin client as the most recent block and the current accepted state of the chain? It seems like this would be a good safeguard - it is very unlikely that the most recent block would ever truly be this old, and preventing a client from accepting a block such as this seems like it might prevent an attack from an adversary trying to pass off an old state of the chain as current.

**Tags:** bitcoin-core, timestamp

> **Comments:**
> **username_1**: It’s not quite clear to me, how we would end up in a scenario where a block with a week old timestamp looks like the best chaintip to us. Do we only have a single peer or are eclipsed in your scenario? Or is there a network split on-going that split off all hashrate from our section of the internet? Does [How does block synchronization work in Bitcoin Core today?](https://bitcoin.stackexchange.com/q/121292/5406) answer your question?  
> **username_0**: Thanks for your answer. Eclipsing is perhaps one way I imagined this might happen, but the context for why I am asking is related to [this paper](https://arxiv.org/abs/2403.08023) that a colleague and I wrote about quantum attacks on PoW and how certain versions of the attack could result in apparently old but high-difficulty chain tips.  

---

## 1 answers

### Answer by username_1 on 2024-07-17. Score: 3 | Accepted answer

Bitcoin Core will generally connect to at least 10 outbound peers (8 regular, 2 blocks-only). It will ask all of the peers for their chaintips and then start synchronizing the header chain for the chaintip with the most work after choosing a single header sync peer. Only when it has acquired all block headers of the peer and validated them to the extent possible, will it start downloading blocks and advancing its active chaintip. As long as one of our node’s peers is honest and caught up, we’d already be on our way to the actual chaintip.

A block whose timestamp is older than the median of the 11 preceding blocks would simply be rejected at the header sync stage, so we must assume that the attacker is serving a blockchain that is a week old.

If our node were to be eclipsed and all of its peers were offering only a chaintip that is older than a week, our node would synchronize with that chaintip. Our node **would remain in "initialblockdownload" state**, as it only disables IBD-mode once the timestamp of the node’s active chaintip is no more than 24 hours in the past of its own system time. This would e.g. cause the wallet GUI to display a warning that the node is not caught up. The node would also start trying to make additional connections due to not making progress. If it finds any honest peer, it will continue synchronizing towards the actual best chain. If the eclipse attack persists, it will stall, but remain in IBD mode.

So, the chaintip would be considered valid, but the node would not consider itself caught up to the network.


---

