path: root/f1/eeeb9913a2b18df41bd09c21b5a4ef733f886b

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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; 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 &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; &gt; If we ban &quot;arbitrary data&quot;, however you want to define =
it, then actors will<br>
&gt; &gt; simply respond by encoding their data within sets of public keys.=
 Public<br>
&gt; &gt; key data is indistinguishable from random data, and, unless we ar=
e willing<br>
&gt; &gt; to pad the blockchain with proof of knowledge of secret keys, the=
re will be<br>
&gt; &gt; no way to tell a priori whether a given public key is really a pu=
blic key<br>
&gt; &gt; or whether it is encoding an inscription or some other data.<br>
&gt; <br>
&gt; <br>
&gt; Note that in the Mimblewimble protocol, range proofs already prove<br>
&gt; knowledge of blinding factor in Pedersen commitments, and thus no<br>
&gt; additional padding is needed there to prevent the encoding of spam<br>
&gt; into cryptographic material. This makes pure MW blockchains the most<b=
r>
&gt; inscription/spam resistant [1].<br>
&gt; <br>
&gt; [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>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <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--