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
176
177
178
179
180
181
182
183
184
185
186
|
Return-Path: <christopher.gilliard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0ADA4C0019
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 16:57:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id E86A283CB3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 16:57:48 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5
tests=[BAYES_40=-0.001, 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: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Fahp4xiInf9z
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 16:57:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com
[IPv6:2607:f8b0:4864:20::22b])
by smtp1.osuosl.org (Postfix) with ESMTPS id 137B683827
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 16:57:45 +0000 (UTC)
Received: by mail-oi1-x22b.google.com with SMTP id e66so15892747oif.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 17 Apr 2021 09:57:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=AboiUqFqt+B/HoyDKC6JMFPUxdV1/ErVKPYAoqqW5+c=;
b=e5OFaNnb2h99qz8oZD3EBjmD3BtpQToJ3HR69zAIHyXnbGefalmrDzd2cxDs42VHsi
eqURl2Y+sFZYLN1qzLH82mTQPZNnGYs8eXapNe0xh+huyLL6bDZ60piJ5eurkTOQfiFA
pGOxydJ+CWoDGIKzn5IX2VIoxIVveS81YLv3SWUsw3BvLF1/eALto153bC9LdzctRrm0
Lg6/0DBNkkXN9EQAOVujQDn8kfBPVgZ6LHhsZscK7IUa1dL/XsoUufu//qOWAXehwLVk
b7fCdAYqn4vV2+3feCYqHm7VDR9GJ4UC3UNA17+x8k6Iv2kgLi2iZEqoaoNrqf2XGyQ9
b+NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=AboiUqFqt+B/HoyDKC6JMFPUxdV1/ErVKPYAoqqW5+c=;
b=s9L1/BZ2XQx2go2TZVQsy+E4pJarS0zT24Uv+6N2Mq1zYCIQNjaorZRvXGOt8wkYli
GjhXFivcHIoQ1XX6RTkaOdsibzTH0a2IqfnnJL09TGic676Sw7nMD1ywc7WojxJR/dQd
iKuN5Xd+cPkkVDezEzdAUdObFY+nrU/TBWKNg2iKCOLu0rjZgd8r9PMyclgNRidz0Yfi
zvOxhFTNoG1DrhmN57g+3vFrrO93J7vxKDk4u2g2BEBb+8vDBJDc0k+/kkekF8jZMtT/
AFM4Di9w3jR9kHgq/x18M7nepQ10ZKsMxTyngKXi9RSFNeKGSf1EJBGKVGkdEpKNnZml
vghA==
X-Gm-Message-State: AOAM533fNManZax33h7AUzuB344cm3O7TD2ae8o73DBzRZuGSGxhQHkP
hh93XiVvZ0FsmVfFa9QJVVeWuaHtQ51lOVbfeN8=
X-Google-Smtp-Source: ABdhPJw4+ZORkzx1RJro2QMKgyZ4B3906ZGmdh5FHxiQDnF/qBngw0Fg0W5DhLoK6P7jIiAFmzc38EkdBvdJ1NikOQU=
X-Received: by 2002:aca:5e55:: with SMTP id s82mr10528323oib.9.1618678665099;
Sat, 17 Apr 2021 09:57:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAK=nyAxOa8fsVfxucH7WTTMn25BCzgQ28h_sNsunedpCoRXjjQ@mail.gmail.com>
<CAMZUoKmR6ZU6mAgEhKDD5cTMuja_OC0_Sz3x4UND=E-g1PkgsQ@mail.gmail.com>
<CAK=nyAz5+yMUA=XDcunA1eeachSisaJoYE2_yzTLj=B0r4=w5A@mail.gmail.com>
<iU2J5dWMIgqAf312ZCNmx38_hcYsKrcuqx84kniWeEdb0wP8jPZPvwHK3P-q1yvmQ5OtdMCwMFqPgwmsL7BUfE8PGUlrxW4rOM3slwHun3E=@protonmail.com>
<CAK=nyAxJ_XYDhTE6pNHqWOQ-cLgqc_f-fbQ+EHTkxyiYOhOPUQ@mail.gmail.com>
<20210417155008.GA3373@petertodd.org>
In-Reply-To: <20210417155008.GA3373@petertodd.org>
From: Christopher Gilliard <christopher.gilliard@gmail.com>
Date: Sat, 17 Apr 2021 16:57:34 +0000
Message-ID: <CAK=nyAzZ5zXt3e68coXMYBhLri4FcCr=kAAo05oiGPVoGH4Ujg@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000d6bd6005c02dfede"
X-Mailman-Approved-At: Sat, 17 Apr 2021 18:16:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
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: Sat, 17 Apr 2021 16:57:49 -0000
--000000000000d6bd6005c02dfede
Content-Type: text/plain; charset="UTF-8"
Peter, thanks for the links. I'm aware that there are other timestamping
aggregation services that already exist, but I had some different ideas
that integrate into some other services. Also thanks for sending the link
to the single use seal asset transfer. I will take a look at that.
On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <pete@petertodd.org> wrote:
> On Sat, Apr 17, 2021 at 03:57:55AM +0000, Christopher Gilliard via
> bitcoin-dev wrote:
> > Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary data
> > in the blockchain and it's not feasible to block all of them. That is why
> > it's important to, at the same time as limiting the OP_RETURN to one per
> > block, also propose and implement a layer 2 solution for timestamping
> > so people have a clear and simple upgrade path. That is what I will be
> > discussing in one of the BIPs I intend to release early next week.
>
> Note that an aggregated timestamping service already exists:
>
> https://petertodd.org/2016/opentimestamps-announcement
>
> But timestamping is useless for most things people want to do, as it can't
> commit to a unique history. It merely proves something existed in the
> past. For
> uniqueness, you need something like:
>
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>
>
> Anyway, at current fees being what they are there's no compelling reason
> to try
> to prevent people from embedding data in the Bitcoin block chain with
> consensus
> changes. Economics is preventing that just fine.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
--000000000000d6bd6005c02dfede
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Peter, thanks for the links. I'm aware that there are =
other timestamping aggregation services that already exist, but I had some =
different ideas that integrate into some other services. Also thanks for se=
nding the link to the single use seal asset transfer. I will take a look at=
that.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_=
attr">On Sat, Apr 17, 2021 at 3:50 PM Peter Todd <<a href=3D"mailto:pete=
@petertodd.org">pete@petertodd.org</a>> wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On Sat, Apr 17, 2021 at 03:57:55AM +0000,=
Christopher Gilliard via bitcoin-dev wrote:<br>
> Thanks ZmnSCPxj. Yes, I agree there are many ways to embed arbitrary d=
ata<br>
> in the blockchain and it's not feasible to block all of them. That=
is why<br>
> it's important to, at the same time as limiting the OP_RETURN to o=
ne per<br>
> block, also propose and implement a layer 2 solution for timestamping<=
br>
> so people have a clear and simple upgrade path. That is what I will be=
<br>
> discussing in one of the BIPs I intend to release early next week.<br>
<br>
Note that an aggregated timestamping service already exists:<br>
<br>
<a href=3D"https://petertodd.org/2016/opentimestamps-announcement" rel=3D"n=
oreferrer" target=3D"_blank">https://petertodd.org/2016/opentimestamps-anno=
uncement</a><br>
<br>
But timestamping is useless for most things people want to do, as it can=
9;t<br>
commit to a unique history. It merely proves something existed in the past.=
For<br>
uniqueness, you need something like:<br>
<br>
<a href=3D"https://petertodd.org/2017/scalable-single-use-seal-asset-transf=
er" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2017/scalabl=
e-single-use-seal-asset-transfer</a><br>
<br>
<br>
Anyway, at current fees being what they are there's no compelling reaso=
n to try<br>
to prevent people from embedding data in the Bitcoin block chain with conse=
nsus<br>
changes. Economics is preventing that just fine.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"=
rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>
--000000000000d6bd6005c02dfede--
|
