Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B6E25C0032 for ; 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 ; 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 ; 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 ; 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 ; 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: In-Reply-To: From: "Russell O'Connor" Date: Mon, 21 Aug 2023 10:47:18 -0400 Message-ID: To: martl.chris@proton.me, Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
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.=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.

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 "arbitrary data", those users will simply respond by &qu= ot;tunneling" their data over innocent-looking public key data instead= .

Please correct me if I'm wrong, but I believ= e 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:2= 9=E2=80=AFAM Chris Martl via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:

It is al= ready 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 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.


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.

=

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.


Here a strategy prop= osal:


Let=E2=80= =99s name it: #Ordisrespector and #Ordislow.

<= br style=3D"line-height:1.5">

Why #Ordisrespector and #Ordislow are compatib= le with a permission-less system.


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


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

Chris________________________= _______________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000002fd52406036ff5ee--