summaryrefslogtreecommitdiff
path: root/af/32f1ce67330459e0f74e8fa8a49a8a14951d22
blob: 8b4126dd8a585d049a30773603fe34514dcefc37 (plain)
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
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
Return-Path: <christophera@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A757FC002A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 21:43:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 7327E402E6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 21:43:12 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7327E402E6
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=lifewithalacrity-com.20221208.gappssmtp.com
 header.i=@lifewithalacrity-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=xPiyM5Wm
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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id TWN9NcgXPqUW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 21:43:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8FA7E4025E
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com
 [IPv6:2a00:1450:4864:20::236])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 8FA7E4025E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  8 May 2023 21:43:10 +0000 (UTC)
Received: by mail-lj1-x236.google.com with SMTP id
 38308e7fff4ca-2ac826a1572so51685221fa.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 08 May 2023 14:43:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=lifewithalacrity-com.20221208.gappssmtp.com; s=20221208; t=1683582188;
 x=1686174188; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=VLV+wgTlQwh4HwL0Y+i0fGxBhaJaRUOY4knLOEJjTO8=;
 b=xPiyM5WmF0a3n35bTUsaUcFe6dFnuNzFQAVhc0CHYSyjH9vYKtfbaDBrFupbDuIRZM
 1fjLEKgXqwQE9haLECvH6PFtuSVlTU41FtDu9LijF/07uVf8opJn7ZRlOY467YbeWdQT
 MK3GOOki5ZGwSRyMsQ3dkDc5lTZ7uLS//FTTUsTZYhh4RsJUnp/HnnmK9NYS5U3NPs/s
 UxoU+sql4mRM9aiffpCIKLAErKZtvrAz5jUmWC7nTnZOGdA1QH9gYH6LSZTs2htLr/I7
 4nKSwISLyfpLViIPbsdXME1o9PwatFxJynKwO1sxgcuTLdGoTXe1j3WfOH/wPbbpUnnf
 SqvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1683582188; x=1686174188;
 h=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=VLV+wgTlQwh4HwL0Y+i0fGxBhaJaRUOY4knLOEJjTO8=;
 b=OKj3Q6svCm1aNympjKc2jBplIF1I0Oo/7ge5CTTiUQeay++AyWqePYu+HzN79vOOOb
 TmyhqAJTBONvApovUJXkp3Jt+i+SpwW0mP4Dxj8sHllFCliPmBDp6/HiCy5QDi1OefVX
 y0OD35wk2Sww4Ztnwx6t8osaJhyQGMV38hrNpzBMe2Y/p2SC4z9r6nmAo6YMqkD4reZT
 NK/a9v/KgA/dN1CziNbUiynS7HnW6Ipe5XNo/yFhjO5RyIhq6koY5iJzW46y5ZgA3Wiy
 tU7LxoOi2Iw+HFWzOjEbhgyULnZvaiE5wgBfv0+ttows7HfQIikQqyJGOUBA7vFpMDSJ
 +qFg==
X-Gm-Message-State: AC+VfDzQsPrVWnDwmyAx3fM+8T0YSD8/ZAfew5Fpp4QWTlFQzx+hbKwQ
 ZM57KmIkgFUUlHmPhu8ivCKN9tuuqrFPDVE53T8=
X-Google-Smtp-Source: ACHHUZ7PvPiFuthAAK6nEUZtEEcaNlLJxw5p+hF8YOSJ5OFZz7aW+hn6D29+Rgn//4Du12mOK6AnCfbHvTpNd/09VGw=
X-Received: by 2002:a2e:894a:0:b0:2ac:8522:d601 with SMTP id
 b10-20020a2e894a000000b002ac8522d601mr122217ljk.43.1683582187894; Mon, 08 May
 2023 14:43:07 -0700 (PDT)
Received: from 1064022179695 named unknown by gmailapi.google.com with
 HTTPREST; Mon, 8 May 2023 14:43:06 -0700
Received: from 1064022179695 named unknown by gmailapi.google.com with
 HTTPREST; Mon, 8 May 2023 14:42:59 -0700
Mime-Version: 1.0 (Mimestream 0.41.6)
References: <SzOndBJmU5RPVdT2IhiWUmw925vgy-KCwrbWC4_e8tHVj5VWUn-Tr50TjxTczUUDcaVjUJEiuLVmFjfmtZwwvLyuUSkrGVg9uNje2oARArc=@proton.me>
In-Reply-To: <SzOndBJmU5RPVdT2IhiWUmw925vgy-KCwrbWC4_e8tHVj5VWUn-Tr50TjxTczUUDcaVjUJEiuLVmFjfmtZwwvLyuUSkrGVg9uNje2oARArc=@proton.me>
From: Christopher Allen <ChristopherA@lifewithalacrity.com>
Date: Mon, 8 May 2023 14:43:06 -0700
Message-ID: <CACrqygCN-LLttNks-MpBKErZauZyx8hpV=MCgvACRoOcRxETOQ@mail.gmail.com>
To: Moth <moth_oshi@proton.me>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000427b8105fb3586d3"
X-Mailman-Approved-At: Tue, 09 May 2023 01:59:04 +0000
Subject: Re: [bitcoin-dev] Witness script validation to reject arbitrary data
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: Mon, 08 May 2023 21:43:12 -0000

--000000000000427b8105fb3586d3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> From what I understand, things like inscriptions can only be inserted
> between two specific flags - OP_FALSE and OP_IF. Having a validation chec=
k
> to reject witness scripts that have arbitrary data between these two flag=
s
> could be used to reject inscriptions while still allowing all the benefit=
s
> of taproot. This will prevent people from overloading the network with tx=
ns
> geared solely for ordinals and brc-20 tokens.
>

Unfortunately, there are many other ways to =E2=80=9Cinscribe=E2=80=9D othe=
r than that
particular trick.

>
> Is there a reason such a validation check is a bad idea? We already have
> OP_RETURN to store arbitrary data that is limited to 80kb. Was it an
> oversight that arbitrary data can be inserted between OP_FALSE and OP_IF
> when the size limit for witness scripts was lifted as part of taproot?
>

There have been some of us that had hoped for a slightly larger OP_RETURN
such that we can store a tagged root of a hash-tree (~128-512 bytes). For
instance, open time-stamps, ION, and my own privacy-focused Gordian
Envelope (https://www.blockchaincommons.com/introduction/Envelope-Intro/),
all consolidate large sets of proofs into a hash, which we use for L2
proofs-of-inclusion. My own preference is that the size can be large enough
so you can store the hash, optionally have a signature on it, and have a
few bytes for self-describing data (we like CBOR as it is quite small).

All of us held off for years asking for larger OP_RETURN or standardizing
on a pay-to-contract BIP for the techniques we do use because of objections
to putting anything on-chain. But now we are dismayed by the inscription
technique that freeloads on the network mempool, the validation network,
and volunteer unpruned full nodes.

For instance, I host an alternative explora instance (the source code base
used by blockstream.info), offering it publicly via Tor so that there is
more than a single server offering its details. Inscriptions combined with
DOS attacks on Tor is making it more expensive for me to host and maintain
this free privacy service.

There was a recent thread discussing raising the limit on OP_RETURN
https://github.com/bitcoin/bitcoin/issues/27043

Here is an old relevant thread from open time-stamps:
https://github.com/opentimestamps/python-opentimestamps/pull/14

I=E2=80=99m not sure what the solution is. I feel like I=E2=80=99ve been a =
good neighbor
for some time on this topic, always recommending minimal on-chain data, and
now I feel frustrated with this free-rider problem.

=E2=80=94 Christopher Allen

--000000000000427b8105fb3586d3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html><body><div dir=3D"ltr"><span style=3D"color:rgb(155,155,155)">On May =
8, 2023 at 1:16:41 PM, Moth via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-d=
ev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt;=
 wrote:</span><br></div><div class=3D"gmail_quote" dir=3D"ltr">
    <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left-width:1px;border-left-style:solid;border-left-color:rgb(155,155,15=
5)!important;padding-left:1ex;color:rgb(155,155,155)!important" type=3D"cit=
e">
        <div><div></div><div><div dir=3D"auto"><div dir=3D"auto" style=3D"l=
etter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;w=
hite-space:normal;word-spacing:0px;text-decoration:none">From what I unders=
tand, things like inscriptions can only be inserted between two specific fl=
ags - OP_FALSE and OP_IF. Having a validation check to reject witness scrip=
ts that have arbitrary data between these two flags could be used to reject=
 inscriptions while still allowing all the benefits of taproot. This will p=
revent people from overloading the network with txns geared solely=C2=A0for=
 ordinals and brc-20 tokens.=C2=A0</div></div></div></div></blockquote><div=
 class=3D"gmail_quote"><br></div>Unfortunately, there are many other ways t=
o =E2=80=9Cinscribe=E2=80=9D other than that particular trick.<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-style:solid;border-left-color:rgb(155,155,155)!important;=
padding-left:1ex;color:rgb(155,155,155)!important" type=3D"cite"><div><div>=
<div dir=3D"auto"><div dir=3D"auto" style=3D"letter-spacing:normal;text-ali=
gn:start;text-indent:0px;text-transform:none;white-space:normal;word-spacin=
g:0px;text-decoration:none"><br style=3D""></div><div dir=3D"auto" style=3D=
"letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none=
;white-space:normal;word-spacing:0px;text-decoration:none">Is there a reaso=
n such a validation check is a bad idea? We already have OP_RETURN to store=
 arbitrary data that is limited to 80kb. Was it an oversight that arbitrary=
 data can be inserted between OP_FALSE and OP_IF when the size limit for wi=
tness scripts=C2=A0was lifted as part of taproot?=C2=A0</div></div></div></=
div>
    </blockquote><br>
</div><div class=3D"gmail_quote" dir=3D"ltr">There have been some of us tha=
t had hoped for a slightly larger OP_RETURN such that we can store a tagged=
 root of a hash-tree (~128-512 bytes). For instance, open time-stamps, ION,=
 and my own privacy-focused Gordian Envelope (<font color=3D"#419cff"><a hr=
ef=3D"https://www.blockchaincommons.com/introduction/Envelope-Intro/">https=
://www.blockchaincommons.com/introduction/Envelope-Intro/</a></font>), all =
consolidate large sets of proofs into a hash, which we use for L2 proofs-of=
-inclusion. My own preference is that the size can be large enough so you c=
an store the hash, optionally have a signature on it, and have a few bytes =
for self-describing data (we like CBOR as it is quite small).</div><div cla=
ss=3D"gmail_quote" dir=3D"ltr"><br></div><div class=3D"gmail_quote" dir=3D"=
ltr">All of us held off for years asking for larger OP_RETURN or standardiz=
ing on a pay-to-contract BIP for the techniques we do use because of object=
ions to putting anything on-chain. But now we are dismayed by the inscripti=
on technique that freeloads on the network mempool, the validation network,=
 and volunteer unpruned full nodes.=C2=A0</div><div class=3D"gmail_quote" d=
ir=3D"ltr"><br></div><div class=3D"gmail_quote" dir=3D"ltr">For instance, I=
 host an alternative explora instance (the source code base used by <a href=
=3D"http://blockstream.info">blockstream.info</a>), offering it publicly vi=
a Tor so that there is more than a single server offering its details. Insc=
riptions combined with DOS attacks on Tor is making it more expensive for m=
e to host and maintain this free privacy service.</div><div class=3D"gmail_=
quote" dir=3D"ltr"><br></div><div class=3D"gmail_quote" dir=3D"ltr">There w=
as a recent thread discussing raising the limit on OP_RETURN=C2=A0<font col=
or=3D"#419cff"><font color=3D"#419cff"><font color=3D"#419cff"><font color=
=3D"#419cff"><font color=3D"#419cff"><font color=3D"#419cff"><a href=3D"htt=
ps://github.com/bitcoin/bitcoin/issues/27043">https://github.com/bitcoin/bi=
tcoin/issues/27043</a></font></font></font></font></font></font><br></div><=
div class=3D"gmail_quote" dir=3D"ltr"><font color=3D"#419cff"><font color=
=3D"#419cff"><font color=3D"#419cff"><font color=3D"#419cff"><br></font></f=
ont></font></font></div><div class=3D"gmail_quote" dir=3D"ltr"><font color=
=3D"#419cff"><font color=3D"#419cff"><font color=3D"#419cff"><font color=3D=
"#419cff"><div class=3D"gmail_quote" dir=3D"ltr" style=3D"color:rgb(0,0,0)"=
>Here is an old relevant thread from open time-stamps:=C2=A0<a href=3D"http=
s://github.com/opentimestamps/python-opentimestamps/pull/14" style=3D"--dar=
k-color: var(--NSColor_linkColor);">https://github.com/opentimestamps/pytho=
n-opentimestamps/pull/14</a></div><div class=3D"gmail_quote" dir=3D"ltr" st=
yle=3D"color:rgb(0,0,0)"><br></div><div class=3D"gmail_quote" dir=3D"ltr" s=
tyle=3D"color:rgb(0,0,0)">I=E2=80=99m not sure what the solution is. I feel=
 like I=E2=80=99ve been a good neighbor for some time on this topic, always=
 recommending minimal on-chain data, and now I feel frustrated with this fr=
ee-rider problem.</div><div class=3D"gmail_quote" dir=3D"ltr" style=3D"colo=
r:rgb(0,0,0)"><br></div></font></font></font></font></div><div class=3D"gma=
il_quote" dir=3D"ltr">=E2=80=94 Christopher Allen</div><div class=3D"gmail_=
quote" dir=3D"ltr"><br></div></body></html>

--000000000000427b8105fb3586d3--