Re: Open Timestamps

On Fri, Sep 16, 2016 at 10:48:41AM -0400, Wayne Vaughan wrote:
> Mountie - You bring up a good point.  Generating accurate timestamps can be
> problematic if you are relying on any outside system.
> 
> In version 1.0 of Chainpoint <http://chainpoint.org> we included a
> "timestamp" field that contained a non-authoritative Unix timestamp of the
> target_hash.  Upon further consideration and feedback from customers, we
> removed this field from the proof format.  We didn't like having a field
> that didn't represent verifiable data. With Chainpoint 2.0, we use JSON-LD.
> If you need accurate timestamps, you can include a trusted timestamp in the
> data being represented by the targetHash, or you can embed a Chainpoint
> proof inside a JSON-LD document that includes a trusted timestamp.

Do you have some examples of this in action?

> A hash calendar <https://en.wikipedia.org/wiki/Hash_calendar> is a type of
> merkle tree that calculates a merkle root once per second has hashed are
> continually added to the tree. This captures the state of the tree in one
> second intervals.  Systems such as Guardtime's KSI
> <https://eprint.iacr.org/2013/834.pdf> use a hash calendar to generate a
> partial proof. They then aggregate all the merkle roots from the hash
> calendar, construct a new merkle tree, anchor the merkle root in one or
> more sources, extract the proof path for each item in the tree, and append
> the partial proofs with the new data to generate the final proofs.  You can
> build a system using a hash calendar that generates Chainpoint proofs.  Not
> everyone requires this capability so we didn't build it into the base
> protocol.

I think not having this functionality in the protocol is a serious omission.

For OpenTimestamps, from the point of view of the protocol supporting calendars
is very simple. We represent them as a pending attestation, which is nothing
more than a URL that the verifier can use to find further information. If
succesful, the verifier then adds that new timestamp data to the timestamp's
commitment operation graph, and continues verifying.

The advantage though is big: without calendars creating timestamps is very
inconvenient, as you always have to wait for the underlying Bitcoin (or
similar) transaction proving the timestamp to confirm, which takes many
minutes, or even hours. This means that using Chainpoint for applications such
as timestamping PGP signatures or Git commits(1) becomes impractical except in
special, high-value, scenarios.

Meanwhile, for the users who don't need that functionality or can't implement
it (e.g. an offline machine), leaving it out is easy: just don't implement the
pending notary method, and ignore it when verifying timestamps. The
OpenTimestamps client already supports an "upgade" command that adds Bitcoin
attestations to an existing timestamp, so to interoperate with such verifiers
you'd simply upgrade the timestamp before giving it to them.

1) See OpenTimestamp's Git integration: https://github.com/opentimestamps/opentimestamps-client/blob/master/doc/git-integration.md

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org