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 simply allowing 
arbitrary data to continue. In ECDSA, purposely re-using k values 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 public 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 being 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 actors 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=5437464.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

Reply via email to