You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to make nodes have as precise a time as possible and to increase the number of honest nodes reporting a correct time in their blocks, either:
check the local time against any available timeserver and refuse to start unless the diff is more than X seconds; ot
periodically check the time in the background and simply have a correction value that's added to the local time reports upon necessity, thus having fixed many possible local time issues both deliberately and unknowingly incurred.
Maybe for this purpose implement a time server into the Kaspa DNS servers functionality, to a) decrease the internet time servers load and 2) to increase the chance of having the source of correct time in the case of time servers being firewalled out.
Probably (for a case when there are multiple nodes behind a firewall for redundancy, most of which are only aware of each other, and only 1 of them have the full internet access) also implement a time server functionality into the nodes p2p protocol as a fallback and last resort option.
The text was updated successfully, but these errors were encountered:
I think this is centralization, and can probably be exploited by dns nodes (altering of timestamps) to stop participation. I think dns should just be a one-time entry to collect ips for future node start-ups, to query these.
Perhaps a simple warning, to indicate a possible bad clock, might be okay.
In order to make nodes have as precise a time as possible and to increase the number of honest nodes reporting a correct time in their blocks, either:
Maybe for this purpose implement a time server into the Kaspa DNS servers functionality, to a) decrease the internet time servers load and 2) to increase the chance of having the source of correct time in the case of time servers being firewalled out.
Probably (for a case when there are multiple nodes behind a firewall for redundancy, most of which are only aware of each other, and only 1 of them have the full internet access) also implement a time server functionality into the nodes p2p protocol as a fallback and last resort option.
The text was updated successfully, but these errors were encountered: