Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3FA65C002D for ; Tue, 14 Jun 2022 15:06:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 173C660E81 for ; Tue, 14 Jun 2022 15:06:36 +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 J9NauN-AeCJp for ; Tue, 14 Jun 2022 15:06:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by smtp3.osuosl.org (Postfix) with ESMTPS id E2F0860ABD for ; Tue, 14 Jun 2022 15:06:34 +0000 (UTC) Received: by mail-wm1-x32f.google.com with SMTP id z9so4824457wmf.3 for ; Tue, 14 Jun 2022 08:06:34 -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; bh=He/wVN0mQFeEsXmFbrS5FOqj9fQvfBL+vORF1U5Up7c=; b=dndWus/jA63dh5V3xu/r1dQEOWJXLxPj8AExf6MI03ROc66Dg0PfDlzxi+/eAMjXAw zeLxFLORJWWlUPxDQ5iu8abcT9pDv8JS5gLPq90mbjOX46vLKRObLVcwPnMNt280jZpH lwL20kLnwNaz/43QnxxiE7Uo2Z6iPvbfTqPFp/GI7GTjl9xfA3lxTMVcFyc3rZKJjdGm XynSEjNZmiRj42EpTeEOZofyxHaMtcMnuehuTTV1FtyXe3sDVRsMVprlO4DNV0MmRpjd PQQdLeJRi0PnFtejWiylyBE8Yz0IR9K1xmxvjSwUyhxOwKpfMAe5z9fpUPxThNhdOrAm IcBA== 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; bh=He/wVN0mQFeEsXmFbrS5FOqj9fQvfBL+vORF1U5Up7c=; b=VAX/W05dweepHHW4LDmc9WRaWkDZIntxijO5Sj4z3rHyoyl9QTKnUTg68Cg69d329k m9wjrx5MSPDPjJYizojPzDw0pWLHpH8QySj005mTGs6ULE3DVZ5X+D8QEL8NP4Mlr1Js sOjC2siSWcjO5oyeE5BJglqqmYubm0Tj71+JM+3gT8UJNhCP1YVIqrBu2UvnVpctuIbr IWV5iiKyaRsA4mSpSpgSOl1oTxTq8YypdyyBl3LCfgwF0aPv7G+5P+2MHVVxW4nMPfmt J3aaP2XbVtSAgmrhEScy5cxr2ghw6GW3lP8ulgtpYCKvnTWHYfS0KtleYFYpu/sXgw6k aPqg== X-Gm-Message-State: AOAM532gaE+4a0tRVDBN0sMUa0314QQ+H0C54BZJw9UWMTjKLGbyIeq7 KVL543PshUD/n9CWo4Yi+yQ3mKz8R6bvLrLc/XIjWPRtYc8= X-Google-Smtp-Source: ABdhPJyjmWev0vvdEIWUYqyv4Hd8Yh3KdY11pr3yvkenkXHyEaqIkYLtyCblNmmc+VRl3RoFQWWxDP95efJhZ69yIJ0= X-Received: by 2002:a05:600c:33a5:b0:39c:7129:c0c9 with SMTP id o37-20020a05600c33a500b0039c7129c0c9mr4557288wmp.194.1655219192755; Tue, 14 Jun 2022 08:06:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: digital vagabond Date: Tue, 14 Jun 2022 17:06:22 +0200 Message-ID: To: Bryan Bishop , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000027b4605e169c093" X-Mailman-Approved-At: Tue, 14 Jun 2022 15:19:35 +0000 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 15:06:36 -0000 --000000000000027b4605e169c093 Content-Type: text/plain; charset="UTF-8" If someone wants more linearity and uniqueness guarantees from a timestamp, that isnt what OTS was designed for. Here is a protocol that was: https://www.commerceblock.com/mainstay/ On Tue, Jun 14, 2022, 3:56 PM Bryan Bishop via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000027b4605e169c093 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If someone wants more linearity and uniqueness guarantees= from a timestamp, that isnt what OTS was designed for. Here is a protocol = that was:=C2=A0https://= www.commerceblock.com/mainstay/

On Tue, Jun 14, 2022, 3:56 PM Bryan Bish= op via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Jun 14, 20= 22 at 8:48 AM Undiscussed Horrific Abuse, One Victim of Many via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
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

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000027b4605e169c093--