The reason I think the 20 hour current scheme is better is this:
| 1 | 0.041666667 | 0.05 |
| 2 | 0.083333333 | 0.1 |
| 3 | 0.125 | 0.15 |
| 4 | 0.166666667 | 0.2 |
| 5 | 0.208333333 | 0.25 |
| 6 | 0.25 | 0.3 |
The second column is increments for the 24 hour change, the second for the 20 hour. As you can see, 24 hours means dealing with rounding. That is fine for Internet apps but an unnecessary source of error for scientific.
Even if Google is converging, there should be coordination or else different companies will converge in different ways. If the only advantage of 24 over 20 is other people expect to do it that way, that is changeable.
One of the reasons I want this is to be able to define secure time for the Mesh. The primary purpose of secure time is to be able to distribute a monotonically increasing counter to nodes at separate locations and to bound the need to store transaction IDs to guard against replay attacks.
I do not want to have to introduce a trusted party just to tell me the leap second schedule so it can track the earth's rotation more precisely.
Instead, I want to fix the leap second schedule by means of a linear approximation for the first 50 years and then by means of a table that is calculated from the divergence between the UTC leap second schedule and the PIT leap second schedule as follows
For y < 2057
PIT (y) = int (L(2016) + (y-2057)/2 )
For y >= 2057
PIT (y) = PIT (y-1) if (PIT (y-50) <= UTC (y-50))
= PIT (y-1)+1 otherwise
With this scheme, the schedule for PIT leap seconds is always known in advance for the next 50 years and will not diverge from UTC by more than 50 seconds unless the number of leap seconds added in a 50 year period exceeds 50.
The expected discrepancy between PIT and UTC is less than 8 seconds. Given that solar noon varies by 1800 seconds over the course of a year, that is near enough.
At the protocol level, I would expect trusted time providers to provide trusted time and precise time separately. So if I have a time authority it would issue a signed timestamp every minute on the minute and respond to requests with an authenticated packet containing the signed timestamp, the current time and the expected lag.
That way I can obtain a very high degree of trust that time X has passed using NIST and the FSB as authorities and also set my clock for UI purposes.
Given the expiry of the Harber and Stornetta patent, signed timestamp should include the prior signature in the output in an intelligent fashion such as a Merkel tree.
On Tue, Jan 3, 2017 at 3:21 PM, Tony Finch <dot@xxxxxxxx> wrote:
"Phillip Hallam-Baker" <phill@xxxxxxxxxxxxxxx> wrote:>> Looking at the problem of time smear, I think Google's 20 hour as opposed> to 24 hours approach is probably best.Google plan to switch from 20h leap smear to 24h