Re: Open Timestamps

When you study the transactions in the blocks in Bitcoin you can see the
timestamps are quite messed up, i.e. not ordered chronologically.

Isn't one of the fundamental attributes of a distributed system the lack of
a global clock?

Recently I'm starting to think that the Bitcoin blockchain only provides a
very fuzzy notion of time stampedness. To me the blockchain is more about a
rough sequencing of events.

Am 16.09.2016 10:02 nachm. schrieb "Wayne Vaughan" <wayne@tierion.com>:

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