I contemplate the “max two hours sooner or later rule” to be a vital community rule of the Bitcoin community; with out it, the system can be woefully insecure. It’s not a mere coverage rule, however it’s also not – and can’t be – a consensus rule as defined in my reply to your different query.
However many different points of a Bitcoin node’s protocol implementation are usually not consensus guidelines. For instance, if validating and relaying blocks is so sluggish that it takes over 10 minutes, the community would fail to converge to a single chain, as a result of miners would by no means be capable to see one another’s blocks in time. I consider the max block timestamp rule as one thing on this class.
The truth that Bitcoin Core in the present day makes use of network-adjusted time to determine what the “native clock” is that block timestamps are in contrast in opposition to, is so far as I am involved an area coverage. In reality, there’s dialogue round dropping the community adjustment half.
So to reply your questions:
- Have I accurately understood the best way network-adjusted time is calculated? Is the “+2h rule” thought-about in relation to it reasonably than the native time (UTC timestamp) of the node?
Sure. At the moment (as of Bitcoin Core 26.0), the network-adjusted time is computed because the native clock plus the median of the friends’ clock variations with our clock. That network-adjusted time is what the “max two hours sooner or later” is evaluating in opposition to.
- Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the native time of the node? I’ve learn totally different info. Right here, they are saying it is 70, and right here, they are saying it is 90 minutes.
It is 70 minutes at present (and has been for so long as I am conscious the rule has existed). Notice that this worth may be overridden with the -maxtimeadjustment command-line flag (or the equal config file setting).
- Does this imply that if I implement my very own node, I solely have to implement the second rule relating to consensus, and my node is totally right, regardless that it could be good to additionally implement the +2h rule since most full nodes run Bitcoin Core, so to all the time be totally synchronized with nearly all of the community?
I assume that relies on your definition of “right”. In case your objective is to write down software program that may determine if a block is legitimate or invalid in line with the consensus guidelines, then this rule is irrelevant.
In case your objective is writing node software program that will be protected for the ecosystem to truly undertake in any economically-relevant setting, then you definitely completely want a way of bounding blocks’ timestamps. It seemingly would not matter that it’s not precisely the identical rule, however you want one thing prefer it.
