path: root/af/32f1ce67330459e0f74e8fa8a49a8a14951d22

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--