Can a Sybil attack get the node stuck? #18118

If a Sybil attack on the node's peer time removes 70 minutes from local time right after the node sees a block with a timestamp that is 120 minutes in the future, does the node get "stuck" in some way?

Not requiring nodes to unilaterally decide world time and not requiring sequential timestamps both violate Byzantine fault tolerance requirements as shown in Lamport et al's original papers. Patches can't fix fundamental holes without doing the mathematical equivalence. Artforz's Zeitgeist/GeistGeld, timespan limit, Culubas timejacking (this potential node problem is an example of it), and all other timestamp attacks are the result of not meeting basic requirements. They're not holes or errors in code, but errors in the design of the consensus mechanism's clock.

https://github.com/bitcoin/bitcoin/commit/c9c017a

Your link is code that compares the blockchain database to the system's local clock at startup as the database is connected and before any nodes are contacted. I don't see how it relates to your comment.

Then the only attack I see is if a Sybil attack pushes the node time forward 70 minutes and attacker finds a block that has a timestamp that is 189 minutes into the future (that nodes outside of the attack will not approve) and if a node restarts in 70 minutes. It seems like an unlikely scenario. I assume the Sybil attack can't motivate a restart.

I guess this is not as bad as regular Culubas timejacking where nodes get a Sybil-attacked peer time that is 70 minutes in the past making them invalidate (for up to 70 minutes or may be longer?) blocks with times forwarded to the 120 minute limit, causing miners under those nodes to build on top of a chain that will lose and can be used for double spending.

I think peer time was always a mistake but Culubas said that if local time was the only time "a disagreement among nodes of only a second or slightly longer (something that will happen as nodes gradually calibrate their clocks) could allow an attacker to split the network or isolate a node." I don't see how that could be done.

That is pretty fringe-- particularly because peer-time only lets a nodes initial peers tweak their time, and mostly serves the purpose of fixing DST handling on windows hosts--, but sure, that startup test could be relaxed by another 70 minutes and not really lose any of it intended sensitivity to misconfigured hosts while avoiding a refusal to start in your suggested oddball confluence of events.

peer-time ... mostly serves the purpose of fixing DST handling

What other purpose does peer time serve?

Allowing a Sybil attack to have control over something that's needed is something that's bad, unless it's beneficial most of the time, and the infrequent subversion is not a net loss.

If it doesn't work, it fails right at node start, and the maximum skew isn't enough to break things generally... Making it fairly uninteresting to attack.

I mean in general, why let a weak consensus mechanism, the median of peer time offset, be part of laying the foundation of POW consensus? BFT requires a clock, so it seems the clock must be more secure than the consensus mechanism.

BTW each message in distributed systems require sequential stamps according to IR2' in Lamport 1978. The MTP(11) gets the baseline, but not requiring it in every block has caused a lot of problems in alts trying to change things.

After studying every timestamp attack it seems they all could have been prevented by following these two rules (in addition to not letting the difficulty algorithm change what the timestamps say and allowing a future timestamp that is greater than node time error but small compared to the difficulty algorithm's averaging window). The requirement for POW to work is not that miners should be able to select the timestamp, but that future nodes connecting must make sure miners do not advance time. Therefore MTP(11) instead of sequential stamps in every block was a mistake.

I just noticed in Lamport's paper he says clocks can't be set backwards. In this context, that means a clock can't be set to before a previously-validated timestamp. This would have prevented the unlikely database error, which is what your suggested patch enforces.

That gives me a total of 5 time requirements for POW consensus:

1. Nodes use their operator as an oracle to set the clock.
2. FTL is > node timing errors & << difficulty averaging window.
3. Sequential stamps on blocks even if it overrides 1 and 2.
4. No calibrating clock back to before a previously-validated stamp.
5. Do not let difficulty algorithm re-interpret the timestamps with things like timespan limits.

The only exception to rule 5 I've seen is that if the difficulty algorithm correctly adjusts and if the other rules are followed, I can't find an attack on symmetrical timespan limits.

Closing due to lack of momentum in the discussion. Can re-open if future interest.