Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 30BBAC0032 for ; Mon, 21 Aug 2023 22:34:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 70BE4408AE for ; Mon, 21 Aug 2023 22:34:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 70BE4408AE Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=proton.me header.i=@proton.me header.a=rsa-sha256 header.s=protonmail header.b=jrDHw7L7 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 Bs72QdZgiKRl for ; Mon, 21 Aug 2023 22:34:22 +0000 (UTC) Received: from mail-4327.protonmail.ch (mail-4327.protonmail.ch [185.70.43.27]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3F13240549 for ; Mon, 21 Aug 2023 22:34:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 3F13240549 Date: Mon, 21 Aug 2023 22:34:03 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="jrDHw7L7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1692657251; x=1692916451; bh=MMBHj3GB9x0hx/F32TxhjTbJUe5swxvsokg5p5g8egg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=jrDHw7L7sWz9kS5dXvxft3UyCWk8irHtW4hqbxkNWvOMoEBHCc0swkHJUobHL5IPD pPyjt0e7XkbDsT7+trYCkFi16D8cm0tUPoC+SDp9ClxhO3Dv6Qb27AFrNF4zlkh8ab 8DyaguawJlEkWlK8xfIqxgAXGF7bCYB2wG8upehKtRAvjekA5yMimolXZuXMs1SGbv Rspd+ygQ+Vq5pkiXDJGT7nTn3Oh8422eNxhs7E6k4ntUP8PTZQlvX+HnxEq1Al9cVY i1JsRqzOchBAl66Fg7VMy4Y6Pkfe6i/K7Nx9YazScGRtqNlk+/wqKL8IKGRxMwfI0n ap/KZWYXNytvw== To: John Tromp From: symphonicbtc Message-ID: In-Reply-To: References: Feedback-ID: 77757318:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 21 Aug 2023 22:46:21 +0000 Cc: Bitcoin Protocol Discussion 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: Mon, 21 Aug 2023 22:34:25 -0000 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. Publi= c > > 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. >=20 >=20 > 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]. >=20 > [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