1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
|
Return-Path: <gmkarl@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 28219C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 12:45:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 16BB840525
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 12:45:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KXfVb4ugRdel
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 12:45:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1130.google.com (mail-yw1-x1130.google.com
[IPv6:2607:f8b0:4864:20::1130])
by smtp2.osuosl.org (Postfix) with ESMTPS id C555C400FE
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 12:45:44 +0000 (UTC)
Received: by mail-yw1-x1130.google.com with SMTP id
00721157ae682-30c143c41e5so28428697b3.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 05:45:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=c8EiNQzSLqJb9dyuklAJRzPXN3cS+lNLe9l1Q0ZLhe8=;
b=MKCqTAemAvRaFIvvh+XuLXOW1XCLiekdir4TxOuc+y+CACQzONnvV2GJ7n2F8xGiEY
0CfHPSXcNFQFVDOUNs+Xi5cwCQSPPYZRPA+rx0u4Puwfth/LGFVBjHcGB4l4z/mMt0u1
QQUHfavWS7IwRoJRm05XauhLCW+sUymjGpNNghYdOeMMpKSMTSPCrN+mkae9WfgUIQFr
zJDAatLQtOfULvpWf6OF7MfHJxgZN32UDyye6VHoFW56zF4PMI0XJ7NhSvkxdldEHE3U
3ZF8KwsJ4+BgQpMmjP1UYQsXYT7DkkbgC3aAsb9LiI7pedujmFV4B1Cg0ZDUhjqWswi2
QKjg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=c8EiNQzSLqJb9dyuklAJRzPXN3cS+lNLe9l1Q0ZLhe8=;
b=7csn1T/ZqyLqyJwqm3kSq+IQlh/EnlKswK77wg6Skb6frrI3/Cudsi1CLFeLCm19JN
Ee685/ubbQ+COS0eznr21n+F1OHU+RTOTJE4AIZ9DfEx+X+JFWuxmjUHUYtCSwzMKSYD
N5H7MHCiYZds0kY5t+wRJSc86GUO9AftMoBnuO1J7h8CpOPxeo3JyJwFE/9VpQuVi3up
CwN2LO/ZZfaScqcSedCEgr0YncPCQ2snLpuoARO9AbXAyD8RSoMcR0orp05lEXUcZc1d
1Qt0XHu9UxxzliGlzyVjE5sQ2fqnaaOH+T1N6kI+8Zbvs9aDNq3PAyt2vnijEht6o3vQ
P1YA==
X-Gm-Message-State: AJIora9v6kg1Su/KzisWmWeGEKb48PFHxJlCAfuQi6GmJc8J07nBTo0W
yX8Grfx/nFVzylVi2z4cuwknX4UqYPNxzpPr3P0=
X-Google-Smtp-Source: AGRyM1t3QU3cZER+P7iMuQHpghxqM3WaO92ESIkX4D2I7dTZRPGv1VAe9hJzVjVxp5qTIBYCPLUY3OlcF2gR1MSJYWg=
X-Received: by 2002:a81:91c3:0:b0:30c:cdd5:8fb8 with SMTP id
i186-20020a8191c3000000b0030ccdd58fb8mr5338973ywg.205.1655210743696; Tue, 14
Jun 2022 05:45:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a05:7000:dd05:0:0:0:0 with HTTP; Tue, 14 Jun 2022 05:45:43
-0700 (PDT)
In-Reply-To: <dy-RmZZGZlQCDyQ_YVeIBIgX4uDW4cfeVpcX5eyugsYoPNZqqjMKs3qoOX_ZidcCBU_3UTytRJMl08TbWQZ363T_E_WQVx_eYJWLzZWUyE8=@protonmail.com>
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>
From: "Undiscussed Horrific Abuse, One Victim of Many" <gmkarl@gmail.com>
Date: Tue, 14 Jun 2022 08:45:43 -0400
Message-ID: <CALL-=e4xA_SVfZp=nLgWRRPon3-6Ke0TE2J0qQrNFGQd7FOsqA@mail.gmail.com>
To: rot13maxi <rot13maxi@protonmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 14 Jun 2022 13:48:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 12:45:46 -0000
hi r1m, i'll talk with you as long as it's fun to do so.
>> 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 =E2=80=9Cthis cont=
ent (or at
> least a digest of this content) existed at least as early as this
> timestamp.=E2=80=9D It says nothing about how long before the timestamp t=
he content
OTS needlessly adds the requirement that the user publicize their .ots
files to everybody who will make use of the timestamp.
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.
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.
>> 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.
> for me. Are there wallets that you=E2=80=99ve seen that incorporate OTS? =
I=E2=80=99d love to
I mean the cryptographic wallets that hold the funds spent in etching
the hash to the chain.
|
