According to this web site, the timing from a system like GPS is essential to "financial networks [which] rely on precision timing for synchronization and operational efficiency." Is the Bitcoin network one of those?
2
-
For example, does the "lock time" function rely on precise timing? coinguides.org/bitcoin-lock-time– brethvoiceAug 23, 2021 at 16:04
-
Also what about knowing the accuracy of blockchain timestamps? Ref this answer: bitcoin.stackexchange.com/a/107019/120379– brethvoiceAug 23, 2021 at 16:07
Add a comment
|
2 Answers
Bitcoin needs approximately sundial time accuracy to operate. Computers have their own free running clocks which provide more than enough accuracy in the absence of other references, and NTP sources which are terrestrial rather than GPS based.
nLockTime and other internal tools are not based on local clocks, as there’s absolutely no guarantee that anybody in the network actually has an accurate one.
A situation in which time sync from GPS, GNSS, Baidu and Galileo were all unavailable would be rather apocalyptic anyway and would transcend the availability of Bitcoin.
-
thank you for guiding me to the NTP information. I had no idea what that stood for until today! ionos.com/digitalguide/server/know-how/… Aug 26, 2021 at 18:09
-
I have heard that the modern financial system, including such simple things as an ATM withdrawal, relies on GPS timing. I wanted to make sure Bitcoin is not just as vulnerable: qz.com/1106064/… Aug 26, 2021 at 18:10
-
@user24925 I just skimmed over S. Nakamoto's whitepaper on $BTC and could not see any specific reference to the level of timing accuracy required. Do you have a reference? Aug 31, 2021 at 17:33
-
The white paper is really an overview of the system, most of the things aren’t really spelled out as such. I don’t know of a reference for how timing works.– ClarisAug 31, 2021 at 18:12
After perusing Satoshi Nakamoto's original paper and this web site, it turns out the only reason time stamps even matter is for implementing what Nakamoto calls the "moving average targeting an average number of blocks per hour" such that if blocks "are generated too fast, the [proof-of-work] difficulty increases." According to the linked web article, the implementation also took potentially falsified time stamps into account, such that there is a 90-minute "maximum allowed gap between the time provided by the nodes and the local system clock" of the node trying to submit a new block.