From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 95E01C0032 for ; 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 ; 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 ; 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 ; 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 ; 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: In-Reply-To: From: Erik Aronesty Date: Wed, 23 Aug 2023 13:34:19 -0400 Message-ID: To: symphonicbtc , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000000ef66206039a86fc" X-Mailman-Approved-At: Wed, 23 Aug 2023 18:17:09 +0000 Cc: John Tromp 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: 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
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

On Mon, Aug 21, 2023 at 6:46=E2=80= =AFPM symphonicbtc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
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.

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 <bit= coin-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://bitcointal= k.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/mail= man/listinfo/bitcoin-dev
--0000000000000ef66206039a86fc--