Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B3A2C002D for ; Tue, 14 Jun 2022 13:56:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5730E60EB6 for ; Tue, 14 Jun 2022 13:56:11 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRvFGPBPGM6I for ; Tue, 14 Jun 2022 13:56:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by smtp3.osuosl.org (Postfix) with ESMTPS id 3F21460E91 for ; Tue, 14 Jun 2022 13:56:10 +0000 (UTC) Received: by mail-lf1-x133.google.com with SMTP id w20so14016573lfa.11 for ; Tue, 14 Jun 2022 06:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZY8A0hyb1j6GtfK+bwxN6jCKC0dTV2ebravhtkr6bbM=; b=PalTOzLihByWKc4xcG++eii02GGZc/hhIjWJbESf2tPflVOdeCivyQ7B9HlZPBi4zC eZhCNq/bNA0ntIP+iunMj0yCKId8cg3KUqs1/mxkrkKoA0rkVreA3kWMbE6YMLK6KVUt 7N21zuCA0co4nEYTCe5u9RemTu1lPIgo4L3NJoTa3KxhhUkOrD/4sI3xNDa5MsnBFoGu BLtUKUrIaCZ6G/PoFeFn8XBx7hcz9/SpkfOxHa0NIsNxzarMAcW/E2bJeUoCc9c7Vb6j zJHcgoiAaBYxiv82PnvEJWYBHhcK2GkDyrl47T02v46saMzoP2JTb3bjgE5ZghRG2itm EJMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZY8A0hyb1j6GtfK+bwxN6jCKC0dTV2ebravhtkr6bbM=; b=mgFvuHMvYsqrMQYC8qJWYqTTkzqApNvBz1Dgl2J9q44XR5t/uDUmWQV3SxNEtExgdh /P+2Wx2Z26ViVApH1rRUx7xTNMAbTDV7Z8ZVUbVgBJ1i9mR6MDcdtZBoYLAs1NnJ93gG 6EJn9vxaEJqNCdt6xEB+HIRLUbcg85sc1rbZcw+4tg0D0v/G8Ef6RyAdISrBwIH5Sq6k Jg275XgXt/SZX9V43c4lxP6PyQZucUuJuu6DntRuKIZ5LtsC8xRUMKhntaKyoBUCIpJQ c1svFWj6fg+El6ddDiyFbZvjJMS3CWp/aNEX8EcDoC7chnTxtV6zc6JqDzSeeZeOD2/9 /dpw== X-Gm-Message-State: AJIora9hL2sHrywpXRqTcbMVmZKhGHxA0p57fb6/j1X6XCG7ZW5p8GW2 sqBXd7OAbZsDLsLRs0ZMkALu5ruyhK/XqeanoOw= X-Google-Smtp-Source: AGRyM1vu24AqoW8+G3M3Bg0bgQyCebZNz0fA6eYJ3MoV2++MwKIySb2Ojdfptx5P5Il3laplWwnXpi2vU6mg/pwk2JQ= X-Received: by 2002:a05:6512:3051:b0:479:1fca:f52f with SMTP id b17-20020a056512305100b004791fcaf52fmr3044157lfb.480.1655214967909; Tue, 14 Jun 2022 06:56:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bryan Bishop Date: Tue, 14 Jun 2022 08:55:55 -0500 Message-ID: To: "Undiscussed Horrific Abuse, One Victim of Many" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000030724005e168c48e" Subject: Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2022 13:56:11 -0000 --00000000000030724005e168c48e Content-Type: text/plain; charset="UTF-8" On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote: > OTS needlessly adds the requirement that the user publicize their .ots > files to everybody who will make use of the timestamp. Publication is not a component of the OTS 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. > (Why would it be needless to require everyone to publish OTS files but not needless to require everyone to publish via OP_RETURN? In fact, now you have blockchain users that don't ever use your OP_RETURN data.) > 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. > You can't replace a timestamp in the OTS system; you can only make a new timestamp. To use the earlier timestamp, you would have to use the earlier timestamp. At any time it is allowed to make a new timestamp based on the current clock. The use case for OTS is proving document existence as of a certain time and that if you had doctored a file then said doctoring was no later than the earliest timestamp that can be provided. I was just talking about this the other day actually... https://news.ycombinator.com/item?id=31640752 - Bryan https://twitter.com/kanzure --00000000000030724005e168c48e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 14, 2022 at 8:48 AM Undiscuss= ed Horrific Abuse, One Victim of Many via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.o= rg> wrote:
OTS needlessly adds the requirement that the user publicize their .ots
files to everybody who will make use of the timestamp.
=C2= =A0
Publication is not a component of the OTS system.
<= br>
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.
=
(Why would it be needless to require everyone to publish OTS files but = not needless to require everyone to publish via OP_RETURN? In fact, now you= have blockchain users that don't ever use your OP_RETURN data.)
=C2= =A0
If I send my .ot= s 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.

You can't replace a= timestamp in the OTS system; you can only make a new timestamp. To use the= earlier timestamp, you would have to use the earlier timestamp. At any tim= e it is allowed to make a new timestamp based on the current clock. The use= case for OTS is proving document existence as of a certain time and that i= f you had doctored a file then said doctoring was no later than the earlies= t timestamp that can be provided.

I was just talking about this the = other day actually...
https://news.ycombinator.com/item?id=3D31640752

=
--00000000000030724005e168c48e--