public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32.com>
To: symphonicbtc <symphonicbtc@proton.me>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Cc: John Tromp <john.tromp@gmail.com>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Date: Wed, 23 Aug 2023 13:34:19 -0400	[thread overview]
Message-ID: <CAJowKg+5NCrnyb9P1uhKvT75dpA=n8hWU4R_DxcUPuVpBvhCEg@mail.gmail.com> (raw)
In-Reply-To: <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=@proton.me>

[-- Attachment #1: Type: text/plain, Size: 2701 bytes --]

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 PM 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 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
>

[-- Attachment #2: Type: text/html, Size: 3672 bytes --]

  reply	other threads:[~2023-08-23 17:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.134025.1692632811.956.bitcoin-dev@lists.linuxfoundation.org>
2023-08-21 16:28 ` [bitcoin-dev] Concern about "Inscriptions" John Tromp
2023-08-21 22:34   ` symphonicbtc
2023-08-23 17:34     ` Erik Aronesty [this message]
2023-09-06  8:00 vjudeu
  -- strict thread matches above, loose matches on Subject: below --
2023-09-03 16:01 vjudeu
2023-09-05 17:49 ` Peter Todd
     [not found] <mailman.11.1692705603.26941.bitcoin-dev@lists.linuxfoundation.org>
2023-08-22 14:18 ` GamedevAlice
2023-08-18 20:43 martl.chris
2023-08-21 14:47 ` Russell O'Connor
2023-08-21 14:58   ` rot13maxi
2023-08-22  5:15   ` martl.chris
2023-08-03 13:33 GamedevAlice
2023-08-03 16:03 ` leohaf
2023-08-02 11:07 GamedevAlice
2023-08-02 15:46 ` Luke Dashjr
2023-07-27 19:03 Léo Haf
2023-07-30 18:34 ` rot13maxi
2023-07-27  5:10 vjudeu
2023-07-26  5:30 vjudeu
2023-07-26  9:46 ` leohaf
2023-07-25 14:11 leohaf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJowKg+5NCrnyb9P1uhKvT75dpA=n8hWU4R_DxcUPuVpBvhCEg@mail.gmail.com' \
    --to=erik@q32.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=john.tromp@gmail.com \
    --cc=symphonicbtc@proton.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox