[ad_1]
In latest instances, I’ve learn many articles and questions/solutions on bitcoin.stackexchange associated to the timestamp, however I nonetheless have issues understanding sure issues. They’re associated to the understanding of sure facets of the “+2h rule” within the context of block acceptance, so I’ve listed them beneath.
Firstly, as I perceive it, a block shall be accepted if its timestamp is as much as 2 hours better than the present network-adjusted time calculated by the given node.
I discovered some solutions associated to network-adjusted time, however I am unsure if I understood it appropriately.
As I perceive every node calculates its network-adjusted time as follows: Upon preliminary connection to friends, the node receives UTC timestamps from all friends within the model message. It calculates the distinction between its present native (system) UTC timestamp and the obtained UTC timestamp from the peer. These variations are sorted, and the median is discovered. The network-adjusted time is obtained by including the present native time (UTC timestamp) of the node and the calculated median. In a really perfect world (a totally synchronized community), network-adjusted time and the native time of the node could be equal since all variations could be 0 and due to this fact the median. Additionally, if the distinction between the present system time (UTC timestamp) of the node and the calculated network-adjusted time (UTC timestamp) is greater than 70/90 minutes, the network-adjusted time is ready to the node’s given system time (UTC timestamp). Thus, when a brand new block arrives, if the block timestamp is throughout the vary of the node native timestamp + beforehand calculated median (native timestamp + median = network-adjusted time of the node) + 2 hours, the block is accepted by that node (assuming that the opposite guidelines are happy).
- Have I appropriately understood the best way network-adjusted time is calculated? Is the “+2h rule” thought-about in relation to it relatively than the native time (UTC timestamp) of the node?
Pieter Wuille right here talked about native clock as a substitute of network-adjusted one. Cite:
An acceptance rule that the timestamp can’t be greater than 2 hours in
future (in comparison with the verifier’s native clock). Since this depends upon
the native clock, this property can change over time (and as soon as sufficient
time passes, a block previously discovered to be invalid by this rule could
change into acceptable).
- Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the native time of the node? I’ve learn completely different data. Right here, they are saying it is 70, and right here, they are saying it is 90 minutes.
From what I perceive to this point, the “+2h rule” is NOT a part of the consensus however solely represents the acceptance coverage of the Bitcoin Core implementation of the Bitcoin full node. The consensus rule is barely that the block timestamp have to be better than the median timestamp of the final 11 blocks.
- Does this imply that if I implement my very own node, I solely must implement the second rule relating to consensus, and my node is solely appropriate, although it will 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?
[ad_2]