How exactly is the timestamp for the +2h approval rule calculated and do I need to implement this on my Bitcoin node for the node to remain valid?
I believe the “up to 2 hours rule in the future” is an essential network rule for the Bitcoin network. Without it, the system would be woefully insecure. This is not a simple policy rule, but as explained in the answer to your other question, it is not and cannot be a consensus rule.
However, there are many other aspects of a Bitcoin node’s protocol implementation other than consensus rules. For example, if block verification and relaying is too slow, taking more than 10 minutes, the network will not converge on a single chain because miners will not be able to see each other’s blocks in time. I think the max block timestamp rule falls into this category.
The fact that Bitcoin Core today uses the network coordinated time to determine a “local clock” against which block timestamps are compared is local policy as far as I’m concerned. In fact, there is discussion about deleting the network adjustment part.
So to answer your question:
- Do I correctly understand how network coordination time is calculated? Is the “+2h rule” rather than the node’s local time (UTC timestamp) considered relevant?
yes. Currently (as of Bitcoin Core 26.0), the network coordinated time is the median of the difference between your computer’s clock as its local clock and our clock’s peer clocks. Network coordination time is a time compared to “up to 2 hours in the future”.
- Is a deviation of 70 or 90 minutes acceptable between the network coordinated time and the node’s local time? I’ve read a lot of different information. Here it says 70 minutes, here it says 90 minutes.
It’s currently 70 minutes (and has been for as long as we know the rule exists). This value can be overridden by: -maxtimeadjustment Command line flags (or equivalent configuration file settings)
- Does this mean that if I implement my node I only need to implement the second rule regarding consensus and since most full nodes run Bitcoin Core it would be nice to implement the +2h rule as well, does this mean my node is completely correct? So will it always be fully synchronized with most networks?
I guess it depends on your definition of “correct”. If your goal is to write software that can determine whether a block is valid or invalid based on consensus rules, this rule is inappropriate.
If your goal is to write node software that is actually safe for the ecosystem to adopt in an economically relevant setting, then having a way to watch out for timestamps on blocks is absolutely necessary. Perhaps it doesn’t matter otherwise. exactly Same rules, but something similar is needed.
