Re: Open Timestamps

On 17 September 2016 at 00:53, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 17 September 2016 at 00:04, S. Matthew English <
> s.matthew.english@gmail.com> wrote:
>
>> 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.
>>
>
> This is correct timestamps are just approximate, they can be several
> minutes out.  In fact, in rare cases they can come out of sequence.  But
> that's not an issue because the block height is another factor which
> enables the ordering.  In fact, bitcoin timestamps cycle round an round, if
> left to go long enough, so the block height becomes an extra vector on top
> of that.
>
> The important thing about bitcoin is not the timestamp, but the ordering.
> I think bitcoin transactions themselves dont have a timestamp at all, only
> the block does.
>

I forgot to add that every block points to the previous block, so there's a
definite order, hence the "chain" in "block chain"


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