Re: Open Timestamps

if you put the topic of yours to github issue (
https://github.com/w3c/blockchain/issues)
then peoples will be able to identify discussion status more easily and
easy to participate.



2016년 9월 17일 (토) 오후 11:20, Peter Todd <pete@petertodd.org>님이 작성:

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