Re: Predictable Internet Time

Phillip Hallam-Baker <> Tue, 03 January 2017 21:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A23B129766 for <>; Tue, 3 Jan 2017 13:57:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1tmHEyOURy4r for <>; Tue, 3 Jan 2017 13:57:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE772129443 for <>; Tue, 3 Jan 2017 13:57:12 -0800 (PST)
Received: by with SMTP id c11so250409886wjx.3 for <>; Tue, 03 Jan 2017 13:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=9lhsuWh+OZWaVSMC4i8ZN4zinzoe+uK0NhWs6Xvx5SY=; b=dXLWljROrKKO33aGaABunhVB/wyzbopuhbkur9yP92e2FpHxBQ+HAE7isU+sdKwTps gDet3tdZWl7d0WKAz1faSMil9PEsr2mUxUKZxb8d6JM4l+TOHVeb7bJ2XX+WjML5ZWjq FGbU+5Ggq3agkHWj2G2nWlrKO7EsoJPHy1PJ01lXlBMSuOmyyypL5sMVW3IIzZqge/DQ lq3EN288eGjzr4KEHCIoOc/fPhdnEepRqurTNnnHoZ9qjnmdEYG7N+SFxe+Qa/yAu1EQ SH/NUwVrYldYGdM64VfgxsvsIRjuKc0s6mwXOHK6lUnwS0uKhl2L3FqHu5JVWOiNOlCv hb5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=9lhsuWh+OZWaVSMC4i8ZN4zinzoe+uK0NhWs6Xvx5SY=; b=Lh4pMz0QawyxgkaiN20ufx6wPhxKbd3vKneeiDdvcCvki6ZF+DD54L1/cysEbf0wc5 EugxLfOksQdM//nzw+h4Q+KGQ4XJxYtaFlHQ4R+EG3w6uysGN5D9qYp2RCz9e9FC/Wbb o47gra6QBDyOlQ4JTfdMWiCTId6dmNW7CNV7BNlc4UkQI52snQ87U9HEZMnlnwSYMq5z tAhMKvxPpr7mUMqwohHNYkUSqVXUwV9L4dD8cwn4Ryghoj9tNc0fJkCt+GnJRGxPfTqR +1wQclbwUHZqgofQy/tRAYweqNIvqwUS68nxQxaY5skupAM0Sj+qpbg4PmVKuAS6apCF 5L/w==
X-Gm-Message-State: AIkVDXK9n4al+Rq0RsT7Q5jJwQsG0DfvAdb73cuyCTkS2fCkc0jFGvE3wh8JcXz4T7o0jIvb5HO6dk14Fg8xTg==
X-Received: by with SMTP id fr7mr52737001wjc.99.1483480631189; Tue, 03 Jan 2017 13:57:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 3 Jan 2017 13:57:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Phillip Hallam-Baker <>
Date: Tue, 03 Jan 2017 16:57:10 -0500
X-Google-Sender-Auth: 7mzn_U6VtsW_M4YIiI_W6o3Mnzg
Message-ID: <>
Subject: Re: Predictable Internet Time
To: Tony Finch <>
Content-Type: multipart/alternative; boundary="047d7bd6bc9c0daa2b054537c0c9"
Archived-At: <>
Cc: IETF Discussion Mailing List <>, Jared Mauch <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 21:57:15 -0000

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

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 <> wrote:

> "Phillip Hallam-Baker" <> 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
> Tony.
> --
> f.anthony.n.finch  <>  -  I xn--zr8h
> punycode