path: root/cb/fd07232b47dcaa681121dd9fe2e83f4bfa94d3

Return-Path: <kanzure@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6B3A2C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Jun 2022 13:56:10 +0000 (UTC)
Received: by mail-lf1-x133.google.com with SMTP id w20so14016573lfa.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <YhAwr7+9mGJAe2/p@petertodd.org>
 <CAD5xwhj1kaJf+QCcf1MOtaAec-xTTr2M9LkJPCu2Ej0L9_3iPg@mail.gmail.com>
 <YlmGv6WbDeDqGJKX@petertodd.org>
 <CAD5xwhgGgq30C7GniNh1_DobPe+P4NTJySUkDiBZBj=OjzO5KA@mail.gmail.com>
 <YmqFRlDIkfbyVIZ2@petertodd.org>
 <CAD5xwhhB+8n+9pWiSCtx3DAPnSwV_7xHnXZ14mEj9H93eWUNEw@mail.gmail.com>
 <YqhtDoN784GG4Cx8@petertodd.org>
 <CALL-=e6ucj0RxM6=Lyrytb3MzQA2pOMwQqM_Gr9RDg3+5Lbudw@mail.gmail.com>
 <CALL-=e4=t7YMxDsBrDvR0Bkhagn+x2XnzZMYuoA4C=VXp=R2KA@mail.gmail.com>
 <dy-RmZZGZlQCDyQ_YVeIBIgX4uDW4cfeVpcX5eyugsYoPNZqqjMKs3qoOX_ZidcCBU_3UTytRJMl08TbWQZ363T_E_WQVx_eYJWLzZWUyE8=@protonmail.com>
 <CALL-=e4xA_SVfZp=nLgWRRPon3-6Ke0TE2J0qQrNFGQd7FOsqA@mail.gmail.com>
In-Reply-To: <CALL-=e4xA_SVfZp=nLgWRRPon3-6Ke0TE2J0qQrNFGQd7FOsqA@mail.gmail.com>
From: Bryan Bishop <kanzure@gmail.com>
Date: Tue, 14 Jun 2022 08:55:55 -0500
Message-ID: <CABaSBawRdyj-f8mdP4gTC=6P3XuXP9iC6YLpOFeiN36-Fkqrkw@mail.gmail.com>
To: "Undiscussed Horrific Abuse, One Victim of Many" <gmkarl@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org> 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

<div dir=3D"ltr"><div dir=3D"ltr">On Tue, Jun 14, 2022 at 8:48 AM Undiscuss=
ed Horrific Abuse, One Victim of Many via bitcoin-dev &lt;<a href=3D"mailto=
:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o=
rg</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">
OTS needlessly adds the requirement that the user publicize their .ots<br>
files to everybody who will make use of the timestamp.</blockquote><div>=C2=
=A0</div><div>Publication is not a component of the OTS system.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This does not provide the service you describe. It would be trivial to<br>
include enough cryptographic information in the original OP_RETURN, so<br>
as to obviate the need for publicizing the .ots file.<br></blockquote><div>=
<br>(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&#39;t ever use your OP_RETURN data.)<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">If I send my .ot=
s file to another party, a 4th party can replace it<br>
with their own, because there is no cryptographic pinning ensuring its<br>
contents. This changes the timestamp to one later, no longer proving<br>
the earliness of the data.<br></blockquote><div><br>You can&#39;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.<br><br>I was just talking about this the =
other day actually...<br><a href=3D"https://news.ycombinator.com/item?id=3D=
31640752">https://news.ycombinator.com/item?id=3D31640752</a><br><br></div>=
</div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">- Bryan<b=
r><a href=3D"https://twitter.com/kanzure" target=3D"_blank">https://twitter=
.com/kanzure</a></div></div></div>

--00000000000030724005e168c48e--