Re: Open Timestamps

On Fri, Sep 16, 2016 at 12:11 PM, Peter Todd <pete@petertodd.org> wrote:

> 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?
>

I'll post some in the Chainpoint Community Group mailing list.


> > 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.


I think you misunderstand. Nothing in Chainpoint precludes you from
implementing a hash calendar. The way that unanchored proofs are handled
requires no changes to the Chainpoint format.  Unlike OpenTimeStamps,
Chainpoint allows you to anchor into multiple sources. We currently support
Bitcoin, Ethereum, and are adding others.  If you retrieve an unanchored
proof, the value for the source can be "unanchored" or a URI of the
developers choice.  Chainpoint is flexible enough to handle unanchored
proofs without any changes to the current format.  If you have a suggestion
about improving the existing mechanism, please make a post in the
Chainpoint Community Group.

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.


I'm cautious about making bold statements about OpenTimeStamps because the
Github commit history shows that until four weeks ago, you had not updated
the code since 2013. The project looks incomplete and you're probably
making changes on a daily basis. The many customers of Tierion find
Chainpoint perfectly suitable for high volume applications.  At the
upcoming Distributed Health conference, I'll be giving a talk about how
Philips used Tierion for protecting the integrity of data collected from
IoT devices.  Several other companies are using Chainpoint, even some
Tierion competitors.  For example, Blockai generates their proofs to be
based on Chainpoint.  Here's a link to a verification tool on their Github.
https://github.com/blockai/blockai-verify

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.


Wayne
----------

[image: Tierion] <http://tierion.com/>

Wayne Vaughan / CEO wayne@tierion.com / 860.836.8633

Tierion http://tierion.com
[image: Twitter] <https://twitter.com/waynevaughan> [image: Linkedin]
<https://linkedin.com/in/wayne> [image: skype]
<https://htmlsig.com/skype?username=w.vaughan>