Date: Mon, 21 Aug 2023 22:34:03 +0000
To: John Tromp <john.tromp@gmail.com>
From: symphonicbtc <symphonicbtc@proton.me>
Message-ID: <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me>
In-Reply-To: <CAOU__fxqf7VpYptKKPpW30RXQHA+g0bA7xy6YOQNy1Of=xYB3A@mail.gmail.com>
References: <mailman.134025.1692632811.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAOU__fxqf7VpYptKKPpW30RXQHA+g0bA7xy6YOQNy1Of=xYB3A@mail.gmail.com>
Feedback-ID: 77757318:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Precedence: list

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 <bitcoi=
n-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. 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