path: root/6a/305a917809a4081e20be4f2c4f0ffb07c18aa7

Return-Path: <roconnor@blockstream.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B6E25C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 14:47:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 8F854405CE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 14:47:32 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8F854405CE
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=blockstream-com.20221208.gappssmtp.com
 header.i=@blockstream-com.20221208.gappssmtp.com header.a=rsa-sha256
 header.s=20221208 header.b=YvUK8eJE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham 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 sXATWjjJycOo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 14:47:31 +0000 (UTC)
Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com
 [IPv6:2607:f8b0:4864:20::62b])
 by smtp4.osuosl.org (Postfix) with ESMTPS id DA9D3405A4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 14:47:30 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DA9D3405A4
Received: by mail-pl1-x62b.google.com with SMTP id
 d9443c01a7336-1bf55a81eeaso9788345ad.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 21 Aug 2023 07:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=blockstream-com.20221208.gappssmtp.com; s=20221208; t=1692629250;
 x=1693234050; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=KE7tGpo6yrG0L2ZHoP9Qd8OGKrU+7wfH6yBZq7WXEPE=;
 b=YvUK8eJEh37uN08hFIjc7oYIqgBI2fzonl2YbETr9ohWYQ7OlxJK0RkXd5/JqQgdtk
 oC7aoFI44yCAD89f/dgl8cb9s0q6gT4w4vrIJFlRswedEFhngSTD1BdRkNBKPfPv7QLa
 ktQtDKZWq5lqaKdS+xccaR5XDFv6wovIgfIKY6HAb6YbMp85MqxXvXR8cU0N9h4koCil
 GL/9LGeXMp+yHndJ8uT12Kra5qK/mqABxrOAJn7pIYD0aohBuXJcX61zVrcdjqep2Plz
 ChUIezJMM2RUPhIpOjV42LHBWbwDTvk1Qx0JNd5ueecNRpT67V48ayV1FxfrHqyiI6mp
 vo2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20221208; t=1692629250; x=1693234050;
 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=KE7tGpo6yrG0L2ZHoP9Qd8OGKrU+7wfH6yBZq7WXEPE=;
 b=Rz6cwodG9fpsIfsN/OQtoH+PwcavYmwaJNpuNbcz6cFtd3fzkHv836Xs57zJBKgm/N
 Yi9oD3uBZu6/wRNFa5uJNEOnuG5ZOQtYCltNCbc2bYLXbfrn/s21+GEzBleAPkS5ghmq
 aflD3JFlquw9rpiwQQ8LZ9WpcCD73nCOrmKG7XfGEOmYmgz5uM9cHg1tXu/KbWMURedp
 Vk7lxcdcmkYpOEuD88w0XW4r0tb8lvSyQkzpnud0yO+ogGFXW6XxVxIDuuiKq1n5B6hL
 ZcD8AS1DXK+LLNgG3IjRCRd9Uk/LIo2bf/W3K09rjhU6NV54k1wEWlURqAovymbmnCv4
 1Z1w==
X-Gm-Message-State: AOJu0YwT2zWmfWt4zEm069IKdlh9LjlJuDgsfhomE0Av1to3pTcJPlGg
 xeGZ8ukHZztzoJMqgGYe75XJVyYcSatr/2zU3TzdSg==
X-Google-Smtp-Source: AGHT+IEYgkng2wD395J5CQvq2uy+PH4YrkPfzBiGwdfNMceX+eQKpTNzdPwBIowYzVmp6iAgLoI4tKkn8IfNMQO4Suk=
X-Received: by 2002:a17:90a:17ec:b0:269:155a:c936 with SMTP id
 q99-20020a17090a17ec00b00269155ac936mr4223232pja.28.1692629250062; Mon, 21
 Aug 2023 07:47:30 -0700 (PDT)
MIME-Version: 1.0
References: <ri0Obd5AcQ2or-gzsFQVqblzEJK7KtEsV3U-bItN8ZsRD47PvurPyR5Vl3CH0Xs-ndSWSxlaiQJ0xvbduTnwwD4dMtOxp-4MMCUyqBCbuZE=@proton.me>
In-Reply-To: <ri0Obd5AcQ2or-gzsFQVqblzEJK7KtEsV3U-bItN8ZsRD47PvurPyR5Vl3CH0Xs-ndSWSxlaiQJ0xvbduTnwwD4dMtOxp-4MMCUyqBCbuZE=@proton.me>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Mon, 21 Aug 2023 10:47:18 -0400
Message-ID: <CAMZUoKnO5zyjGx9DoBUom=E+8vG_UuOCh9wO=2OUPKwAdxtVCg@mail.gmail.com>
To: martl.chris@proton.me, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000002fd52406036ff5ee"
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
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, 21 Aug 2023 14:47:32 -0000

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

It's been said before, but I'll say it again:

If we ban "arbitrary data", however you want to define it, then actors will
simply respond by encoding their data within sets of public keys.  Public
key data is indistinguishable from random data, and, unless we are willing
to pad the blockchain with proof of knowledge of secret keys, there will be
no way to tell a priori whether a given public key is really a public key
or whether it is encoding an inscription or some other data.

When certain governments try to censor certain internet protocols, users
respond by tunnelling their protocol through something that appears to be
innocent HTTPS (see Tor bridge nodes).  This works because, after a
handshake, the remaining HTTPS stream, like public keys, is
indistinguishable from random data, and can be used as a communications
channel for arbitrary data.  If we attempt to ban "arbitrary data", those
users will simply respond by "tunneling" their data over innocent-looking
public key data instead.

Please correct me if I'm wrong, but I believe Counterparty has, in the
past, encoded their data within public key data, so this concern is not
hypothetical.

On Sat, Aug 19, 2023 at 10:29=E2=80=AFAM Chris Martl via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> It is already more than a half year since the probably mayor Bitcoin
> script exploit started.
>
>
> These exploits are nothing new in the Bitcoin history and mostly are due
> to the loose flexibility of the system in regards of processing
> predicatives (Bitcoin script). The very first mayor bug; if you wish,
> vulnerability, was the CVE-2010-5141, which still engages us without end
> even after 14 years.
>
>
> Subsequent Bitcoin historical events let to build more =E2=80=9Cimproveme=
nts=E2=80=9D upon
> this wobbly basis exposing even more ground for exploits.
>
>
> As long as this loose flexibility is not modified in a way its exposure
> for exploits is eliminated remains nothing else than to pursue other
> strategies; and ones which are compatible with the current status quo and
> furthermore, with a permission-less system.
>
>
> Here a strategy proposal:
>
>
> Let=E2=80=99s name it: #Ordisrespector and #Ordislow.
>
>
> Why #Ordisrespector and #Ordislow are compatible with a permission-less
> system.
>
>
> #Ordisrespector gives the option to a regular Bitcoin node operator to
> opt-in or not to a self-defense of his/her storage property (and thus of
> his/her integrity); by giving a signal of dissatisfaction with the curren=
t
> affairs of aggression via insertion of arbitrary data into the witness
> structure. This dissatisfaction signal is manifested by not taking into t=
he
> mempool and relaying transactions with inserted arbitrary data in the
> witness structure.
>
>
> #Ordislow gives the option to a regular Bitcoin node operator to opt-in o=
r
> not to a self-defense of his/her storage property (and thus of his/her
> integrity); by increasing the coercion cost of mining-entities relative t=
o
> the cooperation cost of mining-entities due to the current affairs of
> aggression via insertion of arbitrary data into the witness structure. Th=
is
> coercion cost increment is manifested by not propagating a found block,
> unless a configurable or maximum delay has elapsed, which contains at lea=
st
> a transaction with inserted arbitrary data in the witness structure.
>
>
> Chris_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>It&#39;s been said before, but I&#39;ll say it again:=
</div><div><br></div><div>If we ban &quot;arbitrary data&quot;, however you=
 want to define it, then actors will simply respond by encoding their data =
within sets of public keys.=C2=A0 Public key data is indistinguishable from=
 random data, and, unless we are willing to pad the blockchain with proof o=
f knowledge of secret keys, there will be no way to tell a priori whether a=
 given public key is really a public key or whether it is encoding an inscr=
iption or some other data.</div><div><br></div><div>When certain government=
s try to censor certain internet protocols, users respond by tunnelling the=
ir protocol through something that appears to be innocent HTTPS (see Tor br=
idge nodes).=C2=A0 This works because, after a handshake, the remaining HTT=
PS stream, like public keys, is indistinguishable from random data, and can=
 be used as a communications channel for arbitrary data.=C2=A0 If we attemp=
t to ban &quot;arbitrary data&quot;, those users will simply respond by &qu=
ot;tunneling&quot; their data over innocent-looking public key data instead=
.</div><div><br></div><div>Please correct me if I&#39;m wrong, but I believ=
e Counterparty has, in the past, encoded their data within public key data,=
 so this concern is not hypothetical.<br></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 19, 2023 at 10:2=
9=E2=80=AFAM Chris Martl via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=
=3D"line-height:1.5;text-decoration:none;font-family:Arial,sans-serif"><p s=
tyle=3D"font-size:medium;line-height:normal;margin:0px;font-size-adjust:non=
e;font-kerning:auto;text-decoration:none"><span style=3D"line-height:1.5;fo=
nt-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px">It is al=
ready more than a half year since the probably mayor Bitcoin script exploit=
 started.</span></p><p style=3D"font-size:medium;line-height:normal;margin:=
0px;font-size-adjust:none;font-kerning:auto;min-height:21px;text-decoration=
:none"><span style=3D"line-height:1.5;font-family:UICTFontTextStyleBody;fon=
t-weight:normal;font-size:16px"></span><br style=3D"line-height:1.5"></p><p=
 style=3D"font-size:medium;line-height:normal;margin:0px;font-size-adjust:n=
one;font-kerning:auto;text-decoration:none"><span style=3D"line-height:1.5;=
font-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px">These =
exploits are nothing new in the Bitcoin history and mostly are due to the l=
oose flexibility of the system in regards of processing predicatives (Bitco=
in script). The very first mayor bug; if you wish, vulnerability, was the C=
VE-2010-5141, which still engages us without end even after 14 years.</span=
></p><p style=3D"font-size:medium;line-height:normal;margin:0px;font-size-a=
djust:none;font-kerning:auto;min-height:21px;text-decoration:none"><span st=
yle=3D"line-height:1.5;font-family:UICTFontTextStyleBody;font-weight:normal=
;font-size:16px"></span><br style=3D"line-height:1.5"></p><p style=3D"font-=
size:medium;line-height:normal;margin:0px;font-size-adjust:none;font-kernin=
g:auto;text-decoration:none"><span style=3D"line-height:1.5;font-family:UIC=
TFontTextStyleBody;font-weight:normal;font-size:16px">Subsequent Bitcoin hi=
storical events let to build more =E2=80=9Cimprovements=E2=80=9D upon this =
wobbly basis exposing even more ground for exploits.</span></p><p style=3D"=
font-size:medium;line-height:normal;margin:0px;font-size-adjust:none;font-k=
erning:auto;min-height:21px;text-decoration:none"><span style=3D"line-heigh=
t:1.5;font-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px">=
</span><br style=3D"line-height:1.5"></p><p style=3D"font-size:medium;line-=
height:normal;margin:0px;font-size-adjust:none;font-kerning:auto;text-decor=
ation:none"><span style=3D"line-height:1.5;font-family:UICTFontTextStyleBod=
y;font-weight:normal;font-size:16px">As long as this loose flexibility is n=
ot modified in a way its exposure for exploits is eliminated remains nothin=
g else than to pursue other strategies; and ones which are compatible with =
the current status quo and furthermore, with a permission-less system.</spa=
n></p><p style=3D"font-size:medium;line-height:normal;margin:0px;font-size-=
adjust:none;font-kerning:auto;min-height:21px;text-decoration:none"><span s=
tyle=3D"line-height:1.5;font-family:UICTFontTextStyleBody;font-weight:norma=
l;font-size:16px"></span><br style=3D"line-height:1.5"></p><p style=3D"font=
-size:medium;line-height:normal;margin:0px;font-size-adjust:none;font-kerni=
ng:auto;text-decoration:none"><span style=3D"line-height:1.5;font-family:UI=
CTFontTextStyleBody;font-weight:normal;font-size:16px">Here a strategy prop=
osal:</span></p><p style=3D"font-size:medium;line-height:normal;margin:0px;=
font-size-adjust:none;font-kerning:auto;min-height:21px;text-decoration:non=
e"><span style=3D"line-height:1.5;font-family:UICTFontTextStyleBody;font-we=
ight:normal;font-size:16px"></span><br style=3D"line-height:1.5"></p><p sty=
le=3D"font-size:medium;line-height:normal;margin:0px;font-size-adjust:none;=
font-kerning:auto;text-decoration:none"><span style=3D"line-height:1.5;font=
-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px">Let=E2=80=
=99s name it: #Ordisrespector and #Ordislow.</span></p><p style=3D"font-siz=
e:medium;line-height:normal;margin:0px;font-size-adjust:none;font-kerning:a=
uto;min-height:21px;text-decoration:none"><span style=3D"line-height:1.5;fo=
nt-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px"></span><=
br style=3D"line-height:1.5"></p><p style=3D"font-size:medium;line-height:n=
ormal;margin:0px;font-size-adjust:none;font-kerning:auto;text-decoration:no=
ne"><span style=3D"line-height:1.5;font-family:UICTFontTextStyleBody;font-w=
eight:normal;font-size:16px">Why #Ordisrespector and #Ordislow are compatib=
le with a permission-less system.</span></p><p style=3D"font-size:medium;li=
ne-height:normal;margin:0px;font-size-adjust:none;font-kerning:auto;min-hei=
ght:21px;text-decoration:none"><span style=3D"line-height:1.5;font-family:U=
ICTFontTextStyleBody;font-weight:normal;font-size:16px"></span><br style=3D=
"line-height:1.5"></p><p style=3D"font-size:medium;line-height:normal;margi=
n:0px;font-size-adjust:none;font-kerning:auto;text-decoration:none"><span s=
tyle=3D"line-height:1.5;font-family:UICTFontTextStyleBody;font-weight:norma=
l;font-size:16px">#Ordisrespector gives the option to a regular Bitcoin nod=
e operator to opt-in or not to a self-defense of his/her storage property (=
and thus of his/her integrity); by giving a signal of dissatisfaction with =
the current affairs of aggression via insertion of arbitrary data into the =
witness structure. This dissatisfaction signal is manifested by not taking =
into the mempool and relaying transactions with inserted arbitrary data in =
the witness structure.</span></p><p style=3D"font-size:medium;line-height:n=
ormal;margin:0px;font-size-adjust:none;font-kerning:auto;min-height:21px;te=
xt-decoration:none"><span style=3D"line-height:1.5;font-family:UICTFontText=
StyleBody;font-weight:normal;font-size:16px"></span><br style=3D"line-heigh=
t:1.5"></p><p style=3D"font-size:medium;line-height:normal;margin:0px;font-=
size-adjust:none;font-kerning:auto;text-decoration:none"><span style=3D"lin=
e-height:1.5;font-family:UICTFontTextStyleBody;font-weight:normal;font-size=
:16px">#Ordislow gives the option to a regular Bitcoin node operator to opt=
-in or not to a self-defense of his/her storage property (and thus of his/h=
er integrity); by increasing the coercion cost of mining-entities relative =
to the cooperation cost of mining-entities due to the current affairs of ag=
gression via insertion of arbitrary data into the witness structure. This c=
oercion cost increment is manifested by not propagating a found block, unle=
ss a configurable or maximum delay has elapsed, which contains at least a t=
ransaction with inserted arbitrary data in the witness structure.</span></p=
><p style=3D"font-size:medium;line-height:normal;margin:0px;font-size-adjus=
t:none;font-kerning:auto;text-decoration:none"><span style=3D"line-height:1=
.5;font-family:UICTFontTextStyleBody;font-weight:normal;font-size:16px"><br=
></span></p></div><span style=3D"line-height:1.5;text-decoration:none;font-=
family:Arial,sans-serif"></span><span style=3D"line-height:1.5;text-decorat=
ion:none;font-family:Arial,sans-serif">Chris</span>________________________=
_______________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000002fd52406036ff5ee--