From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <earonesty@gmail.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 95E01C0032 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Aug 2023 17:34:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5731340901 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Aug 2023 17:34:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5731340901 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20221208.gappssmtp.com header.i=@q32-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=IGb6rQgg 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 GMCT_GYAWJM3 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Aug 2023 17:34:30 +0000 (UTC) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) by smtp4.osuosl.org (Postfix) with ESMTPS id 97C05408F4 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Aug 2023 17:34:30 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 97C05408F4 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6b9cd6876bbso1485581a34.1 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 23 Aug 2023 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20221208.gappssmtp.com; s=20221208; t=1692812069; x=1693416869; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/v/pawdO2qmaSTJZNqGsyXXAKuxvYjcaUdXmOOlmV+w=; b=IGb6rQggm8Qa0MCvoyBf4mqt2WUcQyFWy5DrgUqEocK7FpZYrxwfBkT2nFkD7YABQ5 EoI8ILue/kuyPLhuWODf5UdE7y7EzlLHkZu88siX3qFB7fovPP/ZZvQT2v0FrfE1pV7a P/x8UDDcGoURjNvA7KYVkJqzZ4t/3xp1pVjxWe9jMpV7NDQyFX4TAZ4E1/cneTotNcIu Uvqu64YWuUsXJ809dPxq3p61rY+nDEK84koyv3ttpRHfRW+Q2EvDikpT2NaBm6Nk3mvB SxOMjRbPiM6MgbjtO5pzaFldIX5ZmaoEJhLMFoLbdaS7edida7RxOP3yddSithtojYWU id1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692812069; x=1693416869; h=cc: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=/v/pawdO2qmaSTJZNqGsyXXAKuxvYjcaUdXmOOlmV+w=; b=HEn5rph8oVmyErN5zZ42I4Gvb3URYVWkXzsWW/95yMpQf5AD6LxioHlqzk+xcNW/lX NqgvoGguPvIGoEFg3Jm5GQI5f3ESUcMIeOMVyML4yVYgqDRUP0EABPg1evIoqwPjS1MJ aY9V1wbvwN3bofvol2VRA7hnFsIr55lrAiJ64GJ5uV+yDpakhd7mt3nVd3ZGvZYxpHuq eZ3P8CuidBTra4amGdkiyH/nZylU6aBpqSko346+Z321obYJLdRLrjmJHVlMKsX0kYFd YoUPJNNxcglt2qWbi6smi0g1aPZst89lQSdcTZ4LRxWnC1lDnSNtpi7kMGY6HHgH5P2g HcoA== X-Gm-Message-State: AOJu0Yzm4fcXfGezpATwjhzXU0LSw1RdWjuM2J3koFLvkkpjfLY1M1u+ UcgjaN2w5LU49pmRtKCRrMnZPFXDhk3IF2B0Wr9mjS8= X-Google-Smtp-Source: AGHT+IEi86T5vcUB8fSjwauhcTgIntIyz209tJFkhj1VKieKUf7xCWVpMaBkM7aDj7q2QuHe4fmP9dArQLPlRr+3qus= X-Received: by 2002:a05:6358:c12a:b0:13a:cd06:f631 with SMTP id fh42-20020a056358c12a00b0013acd06f631mr8926336rwb.2.1692812069236; Wed, 23 Aug 2023 10:34:29 -0700 (PDT) MIME-Version: 1.0 References: <mailman.134025.1692632811.956.bitcoin-dev@lists.linuxfoundation.org> <CAOU__fxqf7VpYptKKPpW30RXQHA+g0bA7xy6YOQNy1Of=xYB3A@mail.gmail.com> <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me> In-Reply-To: <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me> From: Erik Aronesty <erik@q32.com> Date: Wed, 23 Aug 2023 13:34:19 -0400 Message-ID: <CAJowKg+5NCrnyb9P1uhKvT75dpA=n8hWU4R_DxcUPuVpBvhCEg@mail.gmail.com> To: symphonicbtc <symphonicbtc@proton.me>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="0000000000000ef66206039a86fc" X-Mailman-Approved-At: Wed, 23 Aug 2023 18:17:09 +0000 Cc: John Tromp <john.tromp@gmail.com> 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: Wed, 23 Aug 2023 17:34:32 -0000 --0000000000000ef66206039a86fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable indeed, i once added a proof-of work requirement to public keys on an open relay server protocol, in additon to posk, in order to make it harder to roll new keys and access the network as a spammer/scammer. not hard to embed anything in a public key, but you can't embed too much, especially if you want mobile devices to be able to generate a new key in under a few minutes. On Mon, Aug 21, 2023 at 6:46=E2=80=AFPM symphonicbtc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 simpl= y > allowing arbitrary data to continue. In ECDSA, purposely re-using k value= s > 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 publ= ic > 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 bein= g > 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 actor= s > 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=3D5437464.msg61980991#msg61980991 > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000000ef66206039a86fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">indeed, i once added a proof-of work requirement to public= keys on an open relay server protocol, in additon to posk, in order to mak= e it harder to roll new keys and access the network as a spammer/scammer.= =C2=A0 =C2=A0not hard to embed anything in a public key, but you can't = embed too much, especially if you want mobile devices to be able to generat= e a new key in under a few minutes.=C2=A0</div><br><div class=3D"gmail_quot= e"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 21, 2023 at 6:46=E2=80= =AFPM symphonicbtc via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.= linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<b= r></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">It is important t= o also note that proof of secret key schemes are highly data inefficient an= d 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 encod= e 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 brutef= orce keys in order to encode data in the public key.<br> <br> 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.<br> <br> Symphonic<br> <br> ------- Original Message -------<br> On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <<a = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit= coin-dev@lists.linuxfoundation.org</a>> wrote:<br> <br> <br> > > If we ban "arbitrary data", however you want to define = it, then actors will<br> > > simply respond by encoding their data within sets of public keys.= Public<br> > > key data is indistinguishable from random data, and, unless we ar= e willing<br> > > to pad the blockchain with proof of knowledge of secret keys, the= re will be<br> > > no way to tell a priori whether a given public key is really a pu= blic key<br> > > or whether it is encoding an inscription or some other data.<br> > <br> > <br> > Note that in the Mimblewimble protocol, range proofs already prove<br> > knowledge of blinding factor in Pedersen commitments, and thus no<br> > additional padding is needed there to prevent the encoding of spam<br> > into cryptographic material. This makes pure MW blockchains the most<b= r> > inscription/spam resistant [1].<br> > <br> > [1] <a href=3D"https://bitcointalk.org/index.php?topic=3D5437464.msg61= 980991#msg61980991" rel=3D"noreferrer" target=3D"_blank">https://bitcointal= k.org/index.php?topic=3D5437464.msg61980991#msg61980991</a><br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank">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= /mailman/listinfo/bitcoin-dev</a><br> _______________________________________________<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> --0000000000000ef66206039a86fc--