Re: Open Timestamps

On Fri, Sep 16, 2016 at 04:01:18PM -0400, Wayne Vaughan wrote:
> > Do you have some examples of this in action?
> >
> 
> I'll post some in the Chainpoint Community Group mailing list.

Thanks, let me know when you do.

Looking at the chainpoint-validate-js source code, I don't see how it's
possible to validate anything other than a conventional Bitcoin OP_RETURN
anchor, with a single merkle tree using one hash function. I also don't see any
examples of Chainpoint proofs in the unit tests for anything more complex than
a single, linear, merkle path.

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

FWIW, I considered adding additional PoW blockchains to OpenTimestamps right
away, but decided to leave that out because the actual need to do so is
minimal. The Bitcoin blockchain has proven to be extremely reliable, with a
total of just a few hours of "outages" that could affect the validity of a
timestamp in the entire time it's been in existance. Meanwhile for Ethereum...
which Ethereum are you talking about? The original chain or the bailout chain?

Regardless, adding additional PoW blockchains is not particularly difficult,
just time that I think is better spent elsewhere (Ethereum will inevitably fork
again due to the difficulty bomb, something I'd prefer to avoid wasting time
dealing with!).

Also, I looked at your Node.js module, chainpoint-validate-js, and it appears
to support only Bitcoin OP_RETURN anchors right now; the Ethereum support in
the whitepaper isn't actually implemented. Also, as I mentioned in my blog
post, are a less-than-ideal way of proving a timestamps validity due to the
necessity of having an expensive index of OP_RETURN transactions.

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

So to be clear, ChainPoint 2.0 does not support calendars right now from the
point of view of the verifier, and calendars are not part of the protocol
specification or the reference verifier implementation.

As to why this is important: remember that the purpose of a timestamp is not to
just create a timestamp, but rather to be verifiable later. Much like DNS is
much less useful without the root server infrastructure, timestamps are much
less convenient and less useful without a calendar infrastructure.

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

I think that's an unfair criticism for a few reasons:

1) OpenTimestamps's first Bitcoin support Dec 2012, at which point is supported
most of the current functionality, including calendars, and some functionality
that's since been removed, such as PGP attestations. There were some conceptual
differences to the protocol, such as the fact that at the time calendars
weren't meant to be making a indefinite promise to keep your timestamp
commitment, but regardless it did get some use by people in production, such as
to timestamp server logfiles (I ran a public calendar using the previous
protocol version and saw quite a bit of usage of it). The recent work I've done
rewriting it is in response to lessons learned over a number of years, both in
OpenTimestamps and other timestamping schemes.

2) The code has been updated since 2013: look at the stand-alone
python-opentimestamps implementation which was written last year by client
demand. Since then that code has used by two different clients, one of which in
production (they also wrote a Go library implementing it).

3) ChainPoint is also making changes - as noted above, you're adding more
blockchains, and the protocol doesn't itself have any calendar support.

4) The publicly available ChainPoint codebase is incomplete: unlike
OpenTimestamps I don't see any calendar server, or even a way to create a
timestamp and validate it on the command line. In comparison, OpenTimestamps is
significantly _more_ complete, with an open source client, calendar server, and
Python library available for the most recent version of the protocol.
Regardless, this is a mailing list discussing protocol standardization; we
should be evaluating protocols based on the merits of the protocols themselves.


Incidentally, I noticed your whitepaper credits Proof of Existance (2014) with
pioneering the use of Bitcoin to timestamp data; OpenTimestamps predates Proof
of Existance, and had significantly improved functionality regardless. In turn,
Chronobit predates OpenTimestamps, although I'd consider them separate, as it
wasn't possible to use Chronobit without having access to hashing power (it
made use of the p2pool share chain and required the user to have a miner).
AFAIK OpenTimestamps was the first - and still the only - publicly available
and complete implementation of Bitcoin timestamping that can be used to both
create and verify a timestamp by someone without access to hashing power.

> 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

Note that Blockai is using Chainpoint 1.0, not the current 2.0 version of the
protocol.

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