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 <<a href=3D"mailto= :bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.o= rg</a>> 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'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'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--