public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Undiscussed Horrific Abuse, One Victim of Many" <gmkarl@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions
Date: Tue, 14 Jun 2022 13:15:08 -0400	[thread overview]
Message-ID: <CALL-=e4=p9oQvAxm-dWTNwPOYb5D2kwdLjCtePpCnwNnL9bNVQ@mail.gmail.com> (raw)
In-Reply-To: <YqiqjPternXI1AZ6@petertodd.org>

I'm replying to Peter, skipping the other emails.

I perceive all these emails as disruptive trolling, ignoring the
importance of real timestamping, while handwaving about things that
are roughly false and harmful.

Since the start of cryptocurrency, Bitcoin has been used to write
timestamps that stay intact despite malicious action to arbitrary
systems and records, showing the earliest on-chain publication of
data. It seems misleading that OTS does not do that, when it is such a
prominent system.

>> This does not provide the service you describe. It would be trivial to
>> include enough cryptographic information in the original OP_RETURN, so
>> as to obviate the need for publicizing the .ots file.
>
> That approach does not scale. Via merkle trees, the OpenTimestamps system
> routinely timestamps tens of thousands of messages with a single
> transaction:
>
> https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation

This makes total sense to reduce the expense and size of etching these
very short hashes.

But the OTS approach hashes in a _private nonce_ for every document,
preventing anybody from validating the earliness of an item in a
merkle tree without access to every proof.

Do you think OTS would be interested in publicizing nonces and
document hashes, if the user consents?

Non-developers need a tool where they can choose to pay funds to write
a strong timestamp that guarantees earliness of publication of a
document, and for free discern the earliness of timestamped data they
provide to the tool.

> Client-side validated .ots files are a necessary requirement to achieve
> this
> scalability.

Nothing in an engineering task is a strict requirement, aside from the
specification. The data could be publicised elsewhere, or funds
provided to store it on-chain.

> FWIW the most I've personally done is timestamped 750 million items from
> the
> Internet Archive with a single transaction.

That's impressive. It's always great when we write something that can
condense something huge into something tiny and keep working, and use
it reliably.

I would have put the files in a shared datalad repository, and put the
tip commit of the repository in an OP_RETURN along with a tag such as
'DL' or 'IA'.

Then a tool could look for all 'DL' or 'IA' transactions, and verify
that mine was the earliest. You would of course need access to the
etched repositories' git commits.

If the hash can't be verified by an anonymous observer, the archive is
only timestamped for people with the proof. How is the challenge of
protecting many proofs different from the challenge of protecting the
data they prove?

>> If I send my .ots file to another party, a 4th party can replace it
>> with their own, because there is no cryptographic pinning ensuring its
>> contents. This changes the timestamp to one later, no longer proving
>> the earliness of the data.
>
> They can also simply delete their copy of the data, making it impossible to
> prove anything about it.

If they can destroy your .ots proof, the information on the blockchain
no longer demonstrates anything.


  reply	other threads:[~2022-06-14 17:15 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-01 20:04 [bitcoin-dev] [Pre-BIP] Fee Accounts Jeremy
2022-01-18 16:12 ` Billy Tetrud
2022-01-18 17:43   ` Jeremy
2022-01-19  2:37     ` Billy Tetrud
2022-01-19  2:51       ` Jeremy
2022-01-19  4:53         ` Billy Tetrud
2022-01-19  7:32           ` Jeremy
2022-01-19 16:51             ` Billy Tetrud
2022-01-19 20:08               ` Jeremy
2022-01-20  5:23                 ` Billy Tetrud
2022-02-10  6:58 ` Peter Todd
2022-02-10  8:08   ` Jeremy Rubin
2022-02-18 23:50     ` Peter Todd
2022-02-19  0:38       ` Jeremy Rubin
2022-02-19  9:39         ` Peter Todd
2022-02-19 17:20           ` [bitcoin-dev] [Lightning-dev] " darosior
2022-02-19 20:35             ` Peter Todd
2022-02-20  2:24               ` ZmnSCPxj
2022-02-20  2:39                 ` ZmnSCPxj
     [not found]             ` <590cf52920040c9cf7517b219624bbb5@willtech.com.au>
2022-02-20 14:24               ` ZmnSCPxj
2022-02-20 16:29                 ` Jeremy Rubin
     [not found]                 ` <CAD5xwhgEeTETburW=OBgHNe_V1kk8o06TDQLiLgdfmP2AEVuPg@mail.gmail.com>
2022-02-20 16:34                   ` ZmnSCPxj
2022-02-20 16:45                     ` Jeremy Rubin
2022-02-20 16:29           ` [bitcoin-dev] " Jeremy Rubin
2022-04-10 19:32             ` Peter Todd
2022-04-11 13:18               ` Jeremy Rubin
2022-04-15 14:52                 ` Peter Todd
2022-04-17 20:57                   ` Jeremy Rubin
2022-04-28 12:15                     ` Peter Todd
2022-05-02 15:59                       ` Jeremy Rubin
2022-06-14 11:12                         ` [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions Peter Todd
2022-06-14 11:39                           ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 11:53                             ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 12:28                               ` rot13maxi
2022-06-14 12:45                                 ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-14 13:55                                   ` Bryan Bishop
2022-06-14 15:06                                     ` digital vagabond
2022-06-14 15:34                                   ` Peter Todd
2022-06-14 17:15                                     ` Undiscussed Horrific Abuse, One Victim of Many [this message]
2022-06-14 20:33                                       ` Andrew Poelstra
2022-06-15  1:16                                         ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-15  1:21                                           ` Undiscussed Horrific Abuse, One Victim of Many
2022-06-19 11:04                                           ` Peter Todd
2022-06-14 15:22                               ` Peter Todd

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='CALL-=e4=p9oQvAxm-dWTNwPOYb5D2kwdLjCtePpCnwNnL9bNVQ@mail.gmail.com' \
    --to=gmkarl@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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