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
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
Return-Path: <christophera@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 514FCC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:23:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 1815F40377
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:23:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1815F40377
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=lifewithalacrity-com.20210112.gappssmtp.com
header.i=@lifewithalacrity-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=rdHK2+q8
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
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 OSnGWnhxOlGo
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:23:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E742D40584
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com
[IPv6:2a00:1450:4864:20::22c])
by smtp2.osuosl.org (Postfix) with ESMTPS id E742D40584
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 02:23:08 +0000 (UTC)
Received: by mail-lj1-x22c.google.com with SMTP id g14so17906269ljh.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 31 Jan 2023 18:23:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=lifewithalacrity-com.20210112.gappssmtp.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=e1RMPlUh2RBlOT6bM1YnGhKB7IJ1J3aZ7i2L9wAGZsc=;
b=rdHK2+q8I52ZL6cLD7H1hBKTC9oMZbBBTuVz8cjJHk0xhv+soSb10b5ZLN/mmZ0NSj
+JsKPipFiwQwpDNLPiw2KdmLXVqJhK1qdMZ9iRGAa7ydKdXSFWNqdezxFMby7cRcp1kw
TUGjTacDM3agAgr+c2iOLJMZmRAiNL9kqc75E/JMLonvY79OGt9CIn/AZhZ1/r/setrk
zTOyLI9f69BxS5rtUJbcf9NbA6oq4D2k7fX2Fli6gq01pbZKWjDkh/w5sPOK+AxbWi2H
1kJvtqb0XIlQfyF/tXgxs1ZJB6zUKa1J+tWmLP83VmTEIJ6pPZRJksxSkBlYa/eMXcS8
NN5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=e1RMPlUh2RBlOT6bM1YnGhKB7IJ1J3aZ7i2L9wAGZsc=;
b=tER7gzIjXmrRwuWLagiS74lRAOpaIIzY/Zp0hRl1WrkdIFEWdtwKxYTqCH/aCZL08q
4LgJ3V/hCpcQ4qfZlINUoizmtnT/vBSLK9VT4zKRbYeplNLx+T6FJhufqqqpylxP/dGs
abDr79qvbyoTMf9knet/YS5j82DacT5OyjEa+E2XvsrngDf6qtphq/yjYkh9GE9fdLjz
6oVr5FpH2UwuJFBGzrMSnw5pRWRVvbrPSzQaeFBmriPuKFES28Gj0XrVbnAVTgcweIp0
NKo5wO6tuvqFbEjCp8t8zSdhmWb+JjeRIbNbjM5lWPnFNKSF3jIdBzDdfWV94JowLZaJ
t4+g==
X-Gm-Message-State: AO0yUKX57PR5MvNyGIh9ExYSn8UtrsITydbk3Klxjyb5pKfp+ajUgY2F
5yWLd2CsZ7s0g3vOgOrhyVEo/ZPXDsBKa/3Ig0A=
X-Google-Smtp-Source: AK7set/GbpKGCvmiYRTNNY+38/x5hUr91TchpoeT8xGUygETSBTwKTju1zzoxcSORAqYrCq49/6bDtihS+wuteLZIWI=
X-Received: by 2002:a05:651c:2cd:b0:290:4e11:a3b6 with SMTP id
f13-20020a05651c02cd00b002904e11a3b6mr84369ljo.75.1675218186395; Tue, 31 Jan
2023 18:23:06 -0800 (PST)
MIME-Version: 1.0
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
<764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org>
In-Reply-To: <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Tue, 31 Jan 2023 18:22:29 -0800
Message-ID: <CACrqygD8ZF-PqKuFK7-SgiPdZQ9ewt+9QGXytpf8+NYjjNjyfA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000ebe8f705f39a2094"
X-Mailman-Approved-At: Wed, 01 Feb 2023 02:29:38 +0000
Cc: Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE
OP_IF OP_PUSH
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: Wed, 01 Feb 2023 02:23:10 -0000
--000000000000ebe8f705f39a2094
Content-Type: text/plain; charset="UTF-8"
I don't have a concrete proposal in mind, I'm just trying to understand
various tradeoffs in post-taproot bitcoin in more detail.
On Tue, Jan 31, 2023 at 6:07 PM Peter Todd <pete@petertodd.org> wrote:
>
> >OP_FALSE
> >OP_IF
> >OP_PUSH my64bytes
> >OP_ENDIF
>
> What's wrong with OpPush <data> OpDrop?
>
I'm not sure pro or con of either. I just saw that proposal above recently.
> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The
> whole point of OpReturn is to standardize a way to keep such outputs out of
> the UTXO set. There is the 75% discount to using witness space. But
> considering the size of a transaction as a whole using taproot instead of
> OpReturn doesn't save much.
>
There are OP_RETURN tricks in production that do clog UTXO space. I was
trying to avoid consideration of those by just saying to compare apples vs.
apples, by presuming that any form of these transactions holding the 64
bytes is a spent transaction.
Finally, _64_ bytes is more than a mere 32 byte commitment. What specific
> use case do you actually have in mind here? Are you actually publishing
> data, or simply committing to data? If the latter, you can use ECC
> commitments and have no extra space at all.
>
I chose 64 bytes for this exercise, as I know there are tricks hiding 32
bytes as keys. As almost every op_return live out there is >32 bytes, I
wanted an example that could be a signature, two hashes, a hash plus some
metadata, etc. I also considered 96 bytes (for instance a hash and a
signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice
prohibits comparing the different approaches side-by-side.
To come back to my question another way, if you ignore the people who say
"never put anything except data facilitating coin transactions into the
bitcoin blockchain", but if you also are not trying to use the bitcoin
blockchain as a world database (ala ETH), what is the most pragmatic way to
do so that minimizes any potential harm? The answer pre-taproot was
OP_RETURN. What is it now?
-- Christopher Allen
--000000000000ebe8f705f39a2094
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I don't have a concrete proposal in mind, I'm=
just trying to understand various tradeoffs in post-taproot bitcoin in mor=
e detail.</div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr" c=
lass=3D"gmail_attr">On Tue, Jan 31, 2023 at 6:07 PM Peter Todd <<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex"><br>
>OP_FALSE<br>
>OP_IF<br>
>OP_PUSH my64bytes<br>
>OP_ENDIF<br>
<br>
What's wrong with OpPush <data> OpDrop?<br></blockquote><div><br>=
</div><div>I'm not sure pro or con of either. I just saw that proposal =
above recently.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex">Also, it is incorrec=
t to say that OpReturn outputs "clog UTXO space". The whole point=
of OpReturn is to standardize a way to keep such outputs out of the UTXO s=
et. There is the 75% discount to using witness space. But considering the s=
ize of a transaction as a whole using taproot instead of OpReturn doesn'=
;t save much.<br></blockquote><div><br></div><div>There are OP_RETURN trick=
s in production that do clog UTXO space. I was trying to avoid consideratio=
n of those by just saying to compare apples vs. apples, by presuming that a=
ny form of these transactions holding the 64 bytes is a spent transaction.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-colo=
r:rgb(204,204,204);padding-left:1ex">Finally, _64_ bytes is more than a mer=
e 32 byte commitment. What specific use case do you actually have in mind h=
ere? Are you actually publishing data, or simply committing to data? If the=
latter, you can use ECC commitments and have no extra space at all.<br></b=
lockquote><div><br></div><div>I chose 64 bytes for this exercise, as I know=
there are tricks hiding 32 bytes as keys. As almost every op_return live o=
ut there is >32 bytes, I wanted an example that could be a signature, tw=
o hashes, a hash plus some metadata, etc. I also considered 96 bytes (for i=
nstance a hash and a signature), but as that doesn't fit into OP_RETURN=
's 80 bytes, that choice prohibits comparing the different approaches s=
ide-by-side.</div><div><br></div><div>To come back to my question another w=
ay, if you ignore the people who say "never put anything except data f=
acilitating coin transactions into the bitcoin blockchain", but if you=
also are not trying to use the bitcoin blockchain as a world database (ala=
ETH), what is the most pragmatic way to do so that minimizes any potential=
harm? The answer pre-taproot was OP_RETURN. What is it now?</div><div><br>=
</div><div>-- Christopher Allen</div></div></div>
--000000000000ebe8f705f39a2094--
|
