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
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <gmkarl@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id E2CE0C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 17:15:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id C3EE141899
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 17:15:11 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 4xlMEpLe6ms3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 17:15:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com
[IPv6:2607:f8b0:4864:20::1135])
by smtp4.osuosl.org (Postfix) with ESMTPS id 8CB4D41890
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 17:15:10 +0000 (UTC)
Received: by mail-yw1-x1135.google.com with SMTP id
00721157ae682-30ce6492a60so36585177b3.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 14 Jun 2022 10:15:10 -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; bh=Md8c9FzbuQoCvnmBxi5PctpoDBBtxRxRka68lPaHE7Q=;
b=ZUM5CFlh0fatyPgNvz+vggfj2wE9lbKn28t7Q0x8Snb9SyyOr7u/Ygy07a81rZJqCG
43crm4ErNKL82hlsN9Xwz0nnWIYEQhxRtDBjNaX7Ja0JYHoJPt3mgThK36Ynld/nO7EN
HGjncGfFH12PGg43j0FtWlRbZ67YId7Xac6JpZhbTfY42cRiSNdlPYLZepsD6eMPRD42
zRlI8gEOYVqSl0rNcuj3U+vUhKCZrJrzKCoUlQ3QcGAys9f+XkfMLQFiIkfOoj9DErtt
bgK/FS3rLYNZS3tF7WfmFIPl4x3I0Lg0fRKzSY3v1dnOASdaEk+wPpE/0LA+RMFS5okO
2OyQ==
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;
bh=Md8c9FzbuQoCvnmBxi5PctpoDBBtxRxRka68lPaHE7Q=;
b=ZJnaTMmqjWSCvolM0PzzETbgdyHn5W964pjQokJQGyret9s5Ru26pjTW7Vk0aZ33VH
kk/a4SoITls680NsNRZ6FOFZTI9xW06G1FcTMqZgA2rKyxsHeW5m6eZbbPdRnhKpDio9
EmE1TGuj+OXLRDQ/MFSKV+pNqD9pNqXMFyi7AdYjGppoRhLnFxlDuo51J0g5+YBrs1ZR
B4Fc5vOBGf8ctebHxPG+KvJESs6M7rUGBPQoS08VEGrqpN513KOjF+/RapbrqcVKZ6TO
0vnCamLpIRKUbleawHXmGJHfYPRIz/C8snzwY1qhRSiV5iZ1xU3m0rD86z1YwH1xUOVS
3rLQ==
X-Gm-Message-State: AJIora/VzxUu3KjMAVzF3YT//S2/IxqL7wUhnkrNBmDd2U36uJMtxGnV
Bu3YkMWgIT4eFSZTgjqp3kXI9tgm1isBFKi1WC4=
X-Google-Smtp-Source: AGRyM1tVladkD6ucuJ7FIiyhPp2QhKlfW5zU/HfOsnGfSYdA7NfguPkBiQ6IkSLvnL5UjO7qIEpQIp25Ed+2hoq0oJQ=
X-Received: by 2002:a0d:d8c3:0:b0:314:1e60:89ed with SMTP id
a186-20020a0dd8c3000000b003141e6089edmr6574593ywe.110.1655226909394; Tue, 14
Jun 2022 10:15:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a05:7000:dd05:0:0:0:0 with HTTP; Tue, 14 Jun 2022 10:15:08
-0700 (PDT)
In-Reply-To: <YqiqjPternXI1AZ6@petertodd.org>
References: <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>
<YqiqjPternXI1AZ6@petertodd.org>
From: "Undiscussed Horrific Abuse, One Victim of Many" <gmkarl@gmail.com>
Date: Tue, 14 Jun 2022 13:15:08 -0400
Message-ID: <CALL-=e4=p9oQvAxm-dWTNwPOYb5D2kwdLjCtePpCnwNnL9bNVQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Tue, 14 Jun 2022 17:29:48 +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 17:15:12 -0000
I'm replying to Peter, skipping the other emails.
I perceive all these emails as disruptive trolling, ignoring the
importance of real timestamping, while handwaving about things that
are roughly false and harmful.
Since the start of cryptocurrency, Bitcoin has been used to write
timestamps that stay intact despite malicious action to arbitrary
systems and records, showing the earliest on-chain publication of
data. It seems misleading that OTS does not do that, when it is such a
prominent 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.
>
> That approach does not scale. Via merkle trees, the OpenTimestamps system
> routinely timestamps tens of thousands of messages with a single
> transaction:
>
> https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation
This makes total sense to reduce the expense and size of etching these
very short hashes.
But the OTS approach hashes in a _private nonce_ for every document,
preventing anybody from validating the earliness of an item in a
merkle tree without access to every proof.
Do you think OTS would be interested in publicizing nonces and
document hashes, if the user consents?
Non-developers need a tool where they can choose to pay funds to write
a strong timestamp that guarantees earliness of publication of a
document, and for free discern the earliness of timestamped data they
provide to the tool.
> Client-side validated .ots files are a necessary requirement to achieve
> this
> scalability.
Nothing in an engineering task is a strict requirement, aside from the
specification. The data could be publicised elsewhere, or funds
provided to store it on-chain.
> FWIW the most I've personally done is timestamped 750 million items from
> the
> Internet Archive with a single transaction.
That's impressive. It's always great when we write something that can
condense something huge into something tiny and keep working, and use
it reliably.
I would have put the files in a shared datalad repository, and put the
tip commit of the repository in an OP_RETURN along with a tag such as
'DL' or 'IA'.
Then a tool could look for all 'DL' or 'IA' transactions, and verify
that mine was the earliest. You would of course need access to the
etched repositories' git commits.
If the hash can't be verified by an anonymous observer, the archive is
only timestamped for people with the proof. How is the challenge of
protecting many proofs different from the challenge of protecting the
data they prove?
>> 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.
>
> They can also simply delete their copy of the data, making it impossible to
> prove anything about it.
If they can destroy your .ots proof, the information on the blockchain
no longer demonstrates anything.
|
