Re: Predictable Internet Time

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> wrote:

>
> "Phillip Hallam-Baker" <[e-mail]> 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
>
> https://developers.google.com/time/smear
>
> Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/  -  I xn--zr8h
> punycode
>
>
>