public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Jannes Faber <j.faber@elevate.nl>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps
Date: Sun, 18 Sep 2016 12:05:24 -0400	[thread overview]
Message-ID: <20160918160524.GA13307@fedora-21-dvm> (raw)
In-Reply-To: <CABeL=0jSQsdyRFAUheQ9XSi1krM=PLFAARLXE8Du55FFkX8vZg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2506 bytes --]

On Sun, Sep 18, 2016 at 03:45:40PM +0200, Jannes Faber wrote:
> Would you not also have to consider (all) earlier blocks?
> 
> T = max(block[i].nTime for i in {x-100, ..., x, ..., x + N-1}) + max_offset
> 
> In case one or more previous blocks have an nTime considerably in the
> future and blocks>= x have honest nTimes (or before true time).
> 
> Maybe not strictly for the goal you were describing here (conservative
> estimate) but rather to prevent distinct timestamp events seeming to have
> happened in the wrong order?

Well that's the thing: timestamps are simply proofs that something existed
prior to some time, nothing more, nothing less.

So it doesn't make sense for there to be any notion of the "wrong order" in a
timestamp proof; the proof either is or is not valid, but that has nothing to
do with other proofs. Additionally, the architecture of OpenTimestamps doesn't
and can't make any 100% guarantees about the apparent order of timestamps,
because it's always possible for an earlier timestamp to end up committed in
the blockchain after a later timestamp gets committed. It's not all that likely
of an event, but it is possible.

If you don't want that to be possible, you're going to need a dedicated chain
of transactions for your particular purpose, which adds a lot of complexity,
cost, and makes it much harder to achieve the same level of availability for
the service as a whole.

Remember that for many use-cases the user experience is that there's two or
more claimed dates, and OpenTimestamps simply verifies that those dates are
plausible. Take for example, timestamped git commits:

    commit 536411e73b8c23dc2fdfd78052c893f578444926
    ots: Got 2 attestation(s) from cache
    ots: Success! Bitcoin attests data existed as of Thu Sep 15 01:07:08 2016 EDT
    ots: Good timestamp
    gpg: Signature made Thu 15 Sep 2016 12:10:25 AM EDT
    gpg:                using RSA key 6399011044E8AFB2
    gpg: Good signature from "Peter Todd <pete@petertodd.org>"
    gpg:                 aka "[jpeg image of size 5220]"
    Author: Peter Todd <pete@petertodd.org>
    Date:   Thu Sep 15 00:10:20 2016 -0400

        Release v0.2.0

Here we have the date on the git commit, another date a few seconds later for
the PGP signature, and a third date an hour later for the Bitcoin timestamp,
attesting to the fact that the two other dates for that one git commit are
plausible.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  parent reply	other threads:[~2016-09-18 16:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-18  4:20 [bitcoin-dev] Interpreting nTime for the purpose of Bitcoin-attested timestamps Peter Todd
     [not found] ` <CABeL=0jSQsdyRFAUheQ9XSi1krM=PLFAARLXE8Du55FFkX8vZg@mail.gmail.com>
2016-09-18 16:05   ` Peter Todd [this message]
2016-09-19 16:13 ` Tom Harding
2016-09-19 17:56   ` Peter Todd
2016-09-19 19:53     ` Tom Harding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160918160524.GA13307@fedora-21-dvm \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=j.faber@elevate.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox