They seem to be more frequently off than full nodes.
Maybe we should ignore those?
We're using SPV peer's time to compute our network offset #6071
issue sipa opened this issue on April 27, 2015-
sipa commented at 1:54 PM on April 27, 2015: member
-
laanwj commented at 5:00 PM on May 15, 2015: member
I've never liked adapting our time to the network at all, but this might make sense. This would avoid inadvertent problems. SPV clients have a weaker requirement to have a correct date than full nodes.
- laanwj added the label P2P on May 15, 2015
-
dgenr8 commented at 11:56 PM on August 19, 2015: contributor
@sipa That's not intuitive to me. Where did you observe it? I would think any peer running on a mobile device has an accurate time.
Anyhow, I agree with @laanwj, network-recommended adjustment should be used only to warn the user to check his clock.
The original code said NTP was planned as the "3rd chronometer" but it would be a bad idea to turn bitcoind into an NTP client. Leave it to the system operator to decide how to set his clock well.
The network will still "vote" on the correct time particularly with respect to blockTime validation -- but a remote attack vector against our clock is eliminated.
-
dcousens commented at 1:11 AM on August 20, 2015: contributor
Is the client currently adjusting the system clock?
-
davecgh commented at 2:43 AM on August 20, 2015: contributor
It does not adjust the system clock directly, however the time provided by the system clock is adjusted based upon the time data provided by other nodes on the network before its use within the client.
-
TheBlueMatt commented at 6:23 PM on August 21, 2015: member
I'd say the solution is to only use the network-time-offset in cases where your network time is off from your peers by eg > 1 minute, or so.
- MarcoFalke closed this on Dec 7, 2021
- DrahtBot locked this on Dec 7, 2022
