Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A757FC002A for ; 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 ; 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 ; 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 ; Mon, 8 May 2023 21:43:10 +0000 (UTC) Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2ac826a1572so51685221fa.0 for ; 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: In-Reply-To: From: Christopher Allen Date: Mon, 8 May 2023 14:43:06 -0700 Message-ID: To: Moth , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
On May = 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:
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

Unfortunately, there are many other ways t= o =E2=80=9Cinscribe=E2=80=9D other than that particular trick.
=

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

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 (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 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).

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

For instance, I= host an alternative explora instance (the source code base used by blockstream.info), 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.

There w= as a recent thread discussing raising the limit on OP_RETURN=C2=A0https://github.com/bitcoin/bi= tcoin/issues/27043
<= div class=3D"gmail_quote" dir=3D"ltr">
Here is an old relevant thread from open time-stamps:=C2=A0https://github.com/opentimestamps/pytho= n-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 fr= ee-rider problem.

=E2=80=94 Christopher Allen

--000000000000427b8105fb3586d3--