From: Garlo Nicon <garlonicon@gmail.com>
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
Date: Fri, 31 Oct 2025 14:19:03 +0100 [thread overview]
Message-ID: <CAN7kyNhE39gJyV7xCRNpZAu-jkP7bu2DvkhZ7FdLsGxa-QLjQw@mail.gmail.com> (raw)
In-Reply-To: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]
> if you can embed data into a (P, R, s) tuple (Schnorr pubkey and
signature, BIP340 style), without grinding or using a sidechannel to
"inform" the reader, you must be leaking your private key
You can embed data into a valid signature. For example:
R=k*G
P=d*G
k=first_chunk_of_data
d=second_chunk_of_data
And then, keys are "weak", because people can use "known plaintext attack",
to get them. However, if you want to push random data, that is unknown to
the reader, then it is known only by the holder of the data.
Which means, that the efficiency of this encoding is somewhere around 66%,
by grinding SHA-256 hashes, it could probably reach around 70% in practice.
Only s-value is something, that needs any grinding, for k-value and
d-value, you need only the data, and nothing else.
So, I guess it is a spectrum: something like 70% efficiency means, that you
need "known plaintext attack" to get the data. And then, you can use less
and less bits per public key, to make it arbitrarily weaker. Then, instead
of relying on a timelock, you can rely on computation difficulty for the
reader, for example: "how many bits I need to leak, to make it breakable by
lattice attack".
śr., 1 paź 2025 o 21:50 waxwing/ AdamISZ <ekaggata@gmail.com> napisał(a):
> Hi all,
>
> https://github.com/AdamISZ/schnorr-unembeddability/
>
> Here I'm analyzing whether the following statement is true: "if you can
> embed data into a (P, R, s) tuple (Schnorr pubkey and signature, BIP340
> style), without grinding or using a sidechannel to "inform" the reader, you
> must be leaking your private key".
>
> See the abstract for a slightly more fleshed out context.
>
> I'm curious about the case of P, R, s published in utxos to prevent usage
> of utxos as data. I think this answers in the half-affirmative: you can
> only embed data by leaking the privkey so that it (can) immediately fall
> out of the utxo set.
>
> (To emphasize, this is different to the earlier observations (including by
> me!) that just say it is *possible* to leak data by leaking the private
> key; here I'm trying to prove that there is *no other way*).
>
> However I still am probably in the large majority that thinks it's
> appalling to imagine a sig attached to every pubkey onchain.
>
> Either way, I found it very interesting! Perhaps others will find the
> analysis valuable.
>
> Feedback (especially of the "that's wrong/that's not meaningful" variety)
> appreciated.
>
> Regards,
> AdamISZ/waxwing
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAN7kyNhE39gJyV7xCRNpZAu-jkP7bu2DvkhZ7FdLsGxa-QLjQw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4568 bytes --]
next prev parent reply other threads:[~2025-10-31 13:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-01 14:24 waxwing/ AdamISZ
2025-10-01 22:10 ` Greg Maxwell
2025-10-01 23:11 ` Andrew Poelstra
2025-10-02 0:25 ` waxwing/ AdamISZ
2025-10-02 15:56 ` waxwing/ AdamISZ
2025-10-02 19:49 ` Greg Maxwell
2025-10-06 13:04 ` waxwing/ AdamISZ
2025-10-03 13:24 ` Peter Todd
2025-10-04 2:39 ` waxwing/ AdamISZ
2025-10-07 8:22 ` Anthony Towns
2025-10-07 12:05 ` waxwing/ AdamISZ
2025-10-08 5:12 ` Anthony Towns
2025-10-08 12:55 ` waxwing/ AdamISZ
2025-10-31 9:10 ` Tim Ruffing
2025-10-31 13:09 ` waxwing/ AdamISZ
2025-10-31 13:19 ` Garlo Nicon [this message]
2025-11-01 14:49 ` waxwing/ AdamISZ
2025-11-02 9:11 ` Garlo Nicon
2025-11-02 13:30 ` waxwing/ AdamISZ
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=CAN7kyNhE39gJyV7xCRNpZAu-jkP7bu2DvkhZ7FdLsGxa-QLjQw@mail.gmail.com \
--to=garlonicon@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=ekaggata@gmail.com \
/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