Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9B9D7C0032 for ; Tue, 22 Aug 2023 14:18:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 703C381E61 for ; Tue, 22 Aug 2023 14:18:21 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 703C381E61 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=h7jQRFdU X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3ODGnTjyguE for ; Tue, 22 Aug 2023 14:18:20 +0000 (UTC) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::233]) by smtp1.osuosl.org (Postfix) with ESMTPS id 224E581E49 for ; Tue, 22 Aug 2023 14:18:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 224E581E49 Received: by mail-oi1-x233.google.com with SMTP id 5614622812f47-3a85c5854deso1430511b6e.0 for ; Tue, 22 Aug 2023 07:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692713899; x=1693318699; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=JIoSHl+tl0WEBItukChYou4w7dkLd79cHU8OPCHK3mc=; b=h7jQRFdUUI5ctzPQmUccappcBglGaMya4En4git5yB4appp7hOH69wIT7JGKL9Duoq soW6p3xdRCy5FF4miCQY1GTUeZDJSt6HwMgYDOIQt2wHVdZyuF04IedIcTldXmYzctl3 EjgyAL6rQvq/6rBc0jTooTuQNfPUgVVVMZSaQhhLO8zWmaZ3lBr7cB/0zI3hvkzu878J +gnXweljXqE8VqTiSCj705n/fld76dmYhGhs1abgRDdlIt3xRTZtF1NPoNR5TzXfDP29 Vv32WDcl3B0u8DmKWxXQT7KfgDhUvUawleWjC2ZR4vfETFh/r9LMemodOIKHYl49mFAv tkvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692713899; x=1693318699; 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=JIoSHl+tl0WEBItukChYou4w7dkLd79cHU8OPCHK3mc=; b=jeZmKTnOeszK3UXOPebiEyTf0GIVhVDqJSX0I4KFH0+DcnQ7glvnUnGWSuucPHVw3/ KesMytlGpSInL/a8mYuc5SBTN/9OXigeOdcaHurlQQ5I98OORdATxVia1QMvVYxXCICl 2psfnMsnBNZ3c+D4XcsOjOv0XcVdvlqKD54OI/uFxRX493nTM97YnQrFkb9vLJ0KhS2X INMT4GbY+v2/TPNU6k+Ah1hT62XXL9ImID4rZ7wi32Lo90SeqZSHGH4PVWQIvIuanU2S CCuaWNYY18HZOHew58Rwlgrr/JXfn986YoodQgPPKTs50VoF0wap+0QEAVE43x32anKq 6mrw== X-Gm-Message-State: AOJu0YyT21BbXAIlah+xLgvi6Tg31Aw3TM80UxFpt9m5vI5S8NLSvsAZ ziyaraehcagTjHEHMClt6u8UkxtBa2omXdSQIeB7tYS4 X-Google-Smtp-Source: AGHT+IEBpw7K+4yRYpcTA15RAeawjq1Q7CX0eCjyOgpiKlePZQVmqAn12n8+PnBFVDSSFOnQAS225EWDrtU5gLZJzK8= X-Received: by 2002:a05:6808:1302:b0:3a8:5133:4842 with SMTP id y2-20020a056808130200b003a851334842mr11647435oiv.54.1692713895818; Tue, 22 Aug 2023 07:18:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: GamedevAlice Date: Tue, 22 Aug 2023 10:18:04 -0400 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="000000000000777b39060383aa05" X-Mailman-Approved-At: Fri, 25 Aug 2023 08:44:24 +0000 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: Tue, 22 Aug 2023 14:18:21 -0000 --000000000000777b39060383aa05 Content-Type: text/plain; charset="UTF-8" As I understand it, protecting against this is exactly the reason why a blocksize limit exists. Perhaps it should never have been increased in the first place. Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning? On Tue, Aug 22, 2023, 8:00 AM , < bitcoin-dev-request@lists.linuxfoundation.org> wrote: > Send bitcoin-dev mailing list submissions to > bitcoin-dev@lists.linuxfoundation.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > or, via email, send a message with subject or body 'help' to > bitcoin-dev-request@lists.linuxfoundation.org > > You can reach the person managing the list at > bitcoin-dev-owner@lists.linuxfoundation.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of bitcoin-dev digest..." > > > Today's Topics: > > 1. Re: Concern about "Inscriptions" (symphonicbtc) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 21 Aug 2023 22:34:03 +0000 > From: symphonicbtc > To: John Tromp > Cc: Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Concern about "Inscriptions" > Message-ID: > > proton.me> > > Content-Type: text/plain; charset=utf-8 > > It is important to also note that proof of secret key schemes are highly > data inefficient and likely would have a higher cost for users than simply > allowing arbitrary data to continue. In ECDSA, purposely re-using k values > allows you to encode data in both k and the entire secret key, as both > become computable. Or, one could bruteforce a k value to encode data in a > sig, as is done in some compromised hardware key exfiltration attacks. > Additionally, one can bruteforce keys in order to encode data in the public > key. > > It is very difficult and expensive to attempt to limit the storage of > arbitrary data in a system where the security comes from secret keys being > arbitrary data. > > Symphonic > > ------- Original Message ------- > On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > 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. > > > > > > Note that in the Mimblewimble protocol, range proofs already prove > > knowledge of blinding factor in Pedersen commitments, and thus no > > additional padding is needed there to prevent the encoding of spam > > into cryptographic material. This makes pure MW blockchains the most > > inscription/spam resistant [1]. > > > > [1] > https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ------------------------------ > > End of bitcoin-dev Digest, Vol 99, Issue 43 > ******************************************* > --000000000000777b39060383aa05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understand it, protecting against this is exactly th= e reason why a blocksize limit exists. Perhaps it should never have been in= creased in the first place.

Given th= e current concerns with blockchain size increases due to inscriptions, and = now that the lightning network is starting to gain more traction, perhaps p= eople are now more willing to consider a smaller blocksize in favor of push= ing more activity to lightning?




On Tue, Aug 22, 2023= , 8:00 AM , <bitcoin-dev-request@lists.linuxfoundation.org> wrote:
Send bitcoin-dev mailing list submissions t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfound= ation.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-request@= lists.linuxfoundation.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-owner@list= s.linuxfoundation.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."


Today's Topics:

=C2=A0 =C2=A01. Re: Concern about "Inscriptions" (symphonicbtc)

----------------------------------------------------------------------

Message: 1
Date: Mon, 21 Aug 2023 22:34:03 +0000
From: symphonicbtc <symphonicbtc@proton.me>
To: John Tromp <john.tromp@gmail.com>
Cc: Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxf= oundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUw= ozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=3D@proto= n.me>

Content-Type: text/plain; charset=3Dutf-8

It is important to also note that proof of secret key schemes are highly da= ta inefficient and likely would have a higher cost for users than simply al= lowing arbitrary data to continue. In ECDSA, purposely re-using k values al= lows you to encode data in both k and the entire secret key, as both become= computable. Or, one could bruteforce a k value to encode data in a sig, as= is done in some compromised hardware key exfiltration attacks. Additionall= y, one can bruteforce keys in order to encode data in the public key.

It is very difficult and expensive to attempt to limit the storage of arbit= rary data in a system where the security comes from secret keys being arbit= rary data.

Symphonic

------- Original Message -------
On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:


> > 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 ar= e willing
> > to pad the blockchain with proof of knowledge of secret keys, the= re will be
> > no way to tell a priori whether a given public key is really a pu= blic key
> > or whether it is encoding an inscription or some other data.
>
>
> Note that in the Mimblewimble protocol, range proofs already prove
> knowledge of blinding factor in Pedersen commitments, and thus no
> additional padding is needed there to prevent the encoding of spam
> into cryptographic material. This makes pure MW blockchains the most > inscription/spam resistant [1].
>
> [1] https:/= /bitcointalk.org/index.php?topic=3D5437464.msg61980991#msg61980991
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfou= ndation.org/mailman/listinfo/bitcoin-dev


------------------------------

Subject: Digest Footer

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev


------------------------------

End of bitcoin-dev Digest, Vol 99, Issue 43
*******************************************
--000000000000777b39060383aa05--