Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

From: rot13maxi <rot13maxi@protonmail•com>
To: "Undiscussed Horrific Abuse,
	One Victim of Many" <gmkarl@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions
Date: Tue, 14 Jun 2022 12:28:28 +0000	[thread overview]
Message-ID: <dy-RmZZGZlQCDyQ_YVeIBIgX4uDW4cfeVpcX5eyugsYoPNZqqjMKs3qoOX_ZidcCBU_3UTytRJMl08TbWQZ363T_E_WQVx_eYJWLzZWUyE8=@protonmail.com> (raw)
In-Reply-To: <CALL-=e4=t7YMxDsBrDvR0Bkhagn+x2XnzZMYuoA4C=VXp=R2KA@mail.gmail.com>

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

Good morning Undiscussed Horrific Abuse, One Victim of Many,

> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.

The basic service that a timestamp service provides is “this content (or at least a digest of this content) existed at least as early as this timestamp.” It says nothing about how long before the timestamp the content existed, and says nothing about how long after the timestamp the content continues to exist. It also says nothing about uniqueness or validity of the content. For example, a document that existed for a year before its timestamp and was deleted immediately afterwards, and a document that was created the instant before its timestamp and was retained “forever” afterwards would have timestamp that are equally valid (provided you retained the digest of the document to validate the timestamp in the former case). Assurances around uniqueness (for example, preventing double spends) are a proof-of-publication or set-consistency problem, and assurances around validity are a validation problem. These other semantics can be built into systems that also rely on timestamps, but you can have a useful time stamping system without them. This is what OTS provides. When you say it’s “designed to be broken” do you mean that it claims to provide assurances that it doesn’t, or that the set of assurances that it provides are not a useful set.

> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.

I’ve always used OTS through the cli, which just spits out and works with .ots files, which are sterilized commitment operations. Storage of the ots files for later checking has always been a “problem left to the application” for me. Are there wallets that you’ve seen that incorporate OTS? I’d love to see them!

Best,
rot13maxi

On Tue, Jun 14, 2022 at 7:53 AM, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:

> I was privately asked for more opinions. I am sharing them publicly below:
>
> It's always been clear that OTS proves longness of duration but not
> shortness. It doesn't demonstrate that an earlier work was not
> published, because it hashes each document hash with private material
> the author must separately publicize. Any unpublished private material
> could be an earlier equivalent to a public proof.
>
> the reason i call this 'designed to be broken' is that it lets people
> rewrite history to their stories by republishing other people's
> documents under different contexts.
>
> I would not be surprised if OTS also fails to add tx history
> containing its hashes to associated wallets, letting them be lost in
> chain forks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3626 bytes --]