Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8F91CC0032 for ; Sun, 3 Sep 2023 16:06:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6A61F401DD for ; Sun, 3 Sep 2023 16:06:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6A61F401DD Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=eMhy0w9D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5N_UwlvjbK8f for ; Sun, 3 Sep 2023 16:06:11 +0000 (UTC) X-Greylist: delayed 300 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 03 Sep 2023 16:06:11 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4B5DC400E4 Received: from smtpo45.poczta.onet.pl (smtpo45.poczta.onet.pl [213.180.142.176]) by smtp2.osuosl.org (Postfix) with ESMTPS id 4B5DC400E4 for ; Sun, 3 Sep 2023 16:06:11 +0000 (UTC) Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4RdxML709gzlfc8y; Sun, 3 Sep 2023 18:01:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1693756863; bh=IQX7snPIKiw+B64vKlifuLM1C3Y8rg298EJZ6uNI+PU=; h=From:To:Date:Subject:From; b=eMhy0w9Dxemxnr3NF4J/BitWPQqnJtzCx+pEV1DQECTr6q7Q+N0Rm1JYXYnFylba7 XdpdQmO/zmVqRSYm0y0ReHjoBZyDzQ5JQYv1Wr/7PlVhTRnq5y5y8WDZFxyl4gGB0S bKGS0dKFn/KTYzURE/ujsRgpXoDHHs68vUdkTOOY= Content-Type: multipart/alternative; boundary="===============3218144798102324546==" MIME-Version: 1.0 Received: from [5.173.232.248] by pmq6v.m5r2.onet via HTTP id ; Sun, 03 Sep 2023 18:01:02 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: GamedevAlice , Bitcoin Protocol Discussion , "bitcoin-dev@lists.linuxfoundation.org" Date: Sun, 03 Sep 2023 18:01:02 +0200 Message-Id: <98009035-ac19029087479e992d1f7eccdc9eb0ab@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.232.248;PL;2 X-Mailman-Approved-At: Sun, 03 Sep 2023 21:00:46 +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: Sun, 03 Sep 2023 16:06:13 -0000 This is a multi-part message in MIME format. --===============3218144798102324546== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Given the current concerns with blockchain size increases due to inscript= ions, and now that the lightning network is starting to gain more traction,= perhaps people are now more willing to consider a smaller blocksize in fav= or of pushing more activity to lightning? =C2=A0 People will not agree to shrink the maximum block size. However, if you wan= t to kill inscriptions, there is another approach, that could be used to fo= rce them into second layers: it is called cut-through, and was described in= this topic: https://bitcointalk.org/index.php?topic=3D281848.0 =C2=A0 Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for = example some inscriptions were created in "Alice -> Bob" transaction, then = cut-through could remove those inscriptions, while leaving the payment unaf= fected, because the proper amount of coins will be received by Zack, as it = should be. =C2=A0 On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev wrote: As I understand it, protecting against this is exactly the reason why a blo= cksize limit exists. Perhaps it should never have been increased in the fir= st place. Given the current concerns with blockchain size increases due to inscriptio= ns, and now that the lightning network is starting to gain more traction, p= erhaps people are now more willing to consider a smaller blocksize in favor= of pushing more activity to lightning? =C2=A0 =C2=A0 =C2=A0 On Tue, Aug 22, 2023, 8:00 AM , wrote: Send bitcoin-dev mailing list submissions to =C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfoundation.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.linuxfoundation.org/mailman/listi= nfo/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@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: =C2=A0 =C2=A01. 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Subject: Re: [bitcoin-dev] Concern about "Inscriptions" Message-ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 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 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 will= ing > > to pad the blockchain with proof of knowledge of secret keys, there wil= l be > > no way to tell a priori whether a given public key is really a public k= ey > > 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#msg6198= 0991 > _______________________________________________ > 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 ******************************************* --===============3218144798102324546== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> Given the current concerns with blockchain size increases due to = inscriptions, and now that the lightning network is starting to gain more t= raction, perhaps people are now more willing to consider a smaller blocksiz= e in favor of pushing more activity to lightning?
 
People will not agree to shrink the maximum block size. However, if yo= u want to kill inscriptions, there is another approach, that could be used = to force them into second layers: it is called cut-through, and was describ= ed in this topic: https://bitcointalk.org/index.php?= topic=3D281848.0
 
Then, if you have "Alice -> Bob -> ... -> Zack" transaction c= hain, and for example some inscriptions were created in "Alice -> Bob" t= ransaction, then cut-through could remove those inscriptions, while leaving= the payment unaffected, because the proper amount of coins will be receive= d by Zack, as it should be.


 
On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
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 the current concerns with blockchain size increases= due to inscriptions, and now that the lightning network is starting to gai= n 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 , <<= a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" target=3D"_= blank" rel=3D"noopener">bitcoin-dev-request@lists.linuxfoundation.org&g= t; wrote:
Send bitcoin-dev mailing list submissi= ons to
        bitcoin= -dev@lists.linuxfoundation.org

To subscribe or unsubscribe v= ia the World Wide Web, visit
        https://lists.linuxfoundation.o= rg/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
    &nb= sp;   bitcoin-dev-owner@lists.linuxf= oundation.org

When replying, please edit your Subject line s= o 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 <s= ymphonicbtc@proton.me>
To: John Tromp <john.tromp= @gmail.com>
Cc: Bitcoin Protocol Discussion
    =     <bitcoin-dev@lists.linuxfounda= tion.org>
Subject: Re: [bitcoin-dev] Concern about "Inscription= s"
Message-ID:
        <UMOgM6dqQHqgxIoeyC= E1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IO= D7EJAtdgbqMLe8=3D@proton.me>

Content-Type: tex= t/plain; charset=3Dutf-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 E= CDSA, purposely re-using k values allows you to encode data in both k and t= he 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 k= ey exfiltration attacks. Additionally, one can bruteforce keys in order to = encode data in the public key.

It is very difficult and expensiv= e to attempt to limit the storage of arbitrary data in a system where the s= ecurity comes from secret keys being arbitrary data.

Symphonic
------- Original Message -------
On Monday, August 21st, 202= 3 at 4:28 PM, John Tromp via bitcoin-dev <bi= tcoin-dev@lists.linuxfoundation.org> wrote:


> &g= t; If we ban "arbitrary data", however you want to define it, then actors w= ill
> > simply respond by encoding their data within sets of pub= lic keys. Public
> > key data is indistinguishable from random d= ata, and, unless we are willing
> > to pad the blockchain with p= roof of knowledge of secret keys, there will be
> > no way to te= ll 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 al= ready prove
> knowledge of blinding factor in Pedersen commitments,= and thus no
> additional padding is needed there to prevent the en= coding of spam
> into cryptographic material. This makes pure MW bl= ockchains the most
> inscription/spam resistant [1].
>
> [1] https://bitcointalk.org/index.php?topic=3D5437464.msg61980991#msg619809= 91
> _______________________________________________
> = bitcoin-dev mailing list
> bitcoin-dev@= lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev


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

Su= bject: Digest Footer

___________________________________________= ____
bitcoin-dev mailing list
bitcoin= -dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bi= tcoin-dev


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

En= d of bitcoin-dev Digest, Vol 99, Issue 43
****************************= ***************
--===============3218144798102324546==--