From: waxwing/ AdamISZ <ekaggata@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] On (in)ability to embed data into Schnorr
Date: Mon, 6 Oct 2025 06:04:46 -0700 (PDT) [thread overview]
Message-ID: <b486e5dd-d5b4-43f1-9d9a-20b772d3dc1bn@googlegroups.com> (raw)
In-Reply-To: <CAAS2fgQtx_FnecKxpKryTq9o5HJfirY_Vyih6FXzHGHG2itmQQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4873 bytes --]
Yes, sorry, reading fail on my part (somehow missed that you were
explicitly referring to grinding in the comment).
Still don't think the 12% figure is a good one though? in (P,R,s) it's 8
out of 96 (and as discussed, worse if whole tx is (realistically)
included), 1/4 the rate you get from direct key leakage. (Plus the perhaps
trivial point that it does actually require work, which might conceivably
matter at scale?). I'm not sure why one would not include P in the measure?
Even an explicit multisig that does not sacrifice control of the output
would be of the order of double the embedding rate, without having to do
work. (P,R,s x 2 = 192 and embed 32 for a 1/6 rate; vs. grinding all 4 P,R
values for a 1/12 rate).
On Thursday, October 2, 2025 at 6:59:41 PM UTC-3 Greg Maxwell wrote:
> I just meant in the purely grinding non-key leaking case you could get 4
> bytes into the nonce pretty easily and 4 bytes into either the pubkey or
> signature out of a 64 byte signature. Obviously the delivered embedding
> rate in a whole txn will be lower, but maybe not that much thanks to
> multisig outputs.
>
>
> On Thu, Oct 2, 2025 at 4:17 PM waxwing/ AdamISZ <ekag...@gmail•com> wrote:
>
>> > > 12% embedding rate
>> > Where do you get that number from? 33% for embedding 256 bits in (P, R,
>> s) (but as per this discussion, according to me, at the cost of key
>> leakage). If we include the other bytes in a (taproot anyway) utxo that's
>> not much less, I guess 30% ish. I could try to guess but it'd be easier if
>> you told me :)
>>
>> Thinking about it again: to publish data, you have to publish a
>> transaction! I guess the most economical, paying taproot to taproot, is
>> about 192 bytes with script path plus the posited extra 64 for the (R,s) in
>> the output, so yeah that'd be 32 out of 256, 12.5%. Isn't the figure a bit
>> different for key path though, because no control block? Well it hardly
>> matters, it's some small fraction in that range.
>>
>> An interesting mechanical detail in this near-absurd scenario is that if
>> you wanted to repeatedly publish off the same (presumably a few multiples
>> of dust level) output, you couldn't also do the leak single key thing,
>> since you'd lose control to re-spend. So that'd place us in the "explicit
>> multisig" scenario that Greg mentioned, which I think would only make sense
>> with legacy script? Kind of a different scenario, also it would be really
>> weird to update legacy script to take into account a new "you must sign the
>> pubkeys" rule. Though I guess in this fictional scenario, it might happen
>> like that. If you did do it with legacy, you'd be publishing bare 2 of 2
>> multisig. If you did it with taproot due to how that works, the script is
>> not published until the output is spent, so I think that's outside what I
>> was considering ("data in utxo set"). (I guess you could also use something
>> like a hash lock which might be more efficient). So anyway if you wanted to
>> do this repeatedly and minimize cost, for whatever strange reason, you'd be
>> adding another 50-100 bytes each time bringing that % down to like 10% or
>> less.
>>
>> But that all became way too hypothetical to even analyze properly :)
>>
>> Anyway just to reemphasize I certainly wasn't advocating this
>> sig-attaching system, but it seems important to know what the result of it
>> would be: we would still not have changed the obvious reality that
>> embedding data in witness gives more space for data, and is more
>> economical, and we would only reduce by a big factor how much can be
>> embedded in outputs (anything from 8% to 15% embedding rate seems possible
>> depending on the hypothetical details), while having to screw up much of
>> Bitcoin's functionality in the process.
>>
>> Cheers,
>> 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+...@googlegroups•com.
>>
> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/cf15c24e-18d0-4221-a3d4-4177c82a6381n%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/b486e5dd-d5b4-43f1-9d9a-20b772d3dc1bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6492 bytes --]
next prev parent reply other threads:[~2025-10-06 13:06 UTC|newest]
Thread overview: 13+ 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 [this message]
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
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=b486e5dd-d5b4-43f1-9d9a-20b772d3dc1bn@googlegroups.com \
--to=ekaggata@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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