1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
|
Delivery-date: Wed, 01 Oct 2025 12:50:44 -0700
Received: from mail-qv1-f62.google.com ([209.85.219.62])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDI23FE35EIBBCEM63DAMGQERAGJ5LA@googlegroups.com>)
id 1v42qa-00006m-Cm
for bitcoindev@gnusha.org; Wed, 01 Oct 2025 12:50:44 -0700
Received: by mail-qv1-f62.google.com with SMTP id 6a1803df08f44-78e45d71f05sf6390426d6.2
for <bitcoindev@gnusha.org>; Wed, 01 Oct 2025 12:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1759348238; x=1759953038; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:sender:from:to:cc:subject:date
:message-id:reply-to;
bh=H4e/lNCjHxSgb/BUtjsIOcLRiaHPjhz2f7MCWoAEWd8=;
b=vAH1BNtaPiuxMeCrpJ7OOqpb4xCbEg8ZYRV6mjNr13PNNFk7gIB/4Fo44IQMCc8CAG
bNq6KeslFMJEoa0l3oHPCZssGFNyScECLB1qCV9K+DZlPAPoqovKEdhZEPhknHvjmTb7
JpCmY6mT+SfJpXUKw7OTbKHG1/o9d4F7Wh9G+RUOxdiFht4OgFf8gXlwE9+B6vyQS92c
lEeNCStsHxAUlnDEc23meT2Z1ZnYpUvURxEK7JUB29LdVQSJNa2EH/kKnyhwNoi8gYB+
AiJGmeWIfEKvqceiLrcsk4cayeg4pgFoo3Cpk9I7gZT7iKDaOuf4Jgv6hMlnZMeaby5E
MCrw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759348238; x=1759953038; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:from:to:cc:subject:date:message-id
:reply-to;
bh=H4e/lNCjHxSgb/BUtjsIOcLRiaHPjhz2f7MCWoAEWd8=;
b=GCUoyN9x70ducH8orhjDqxYjKyZfupP2xkZM9j7AlTW3PNYtQP70P+LzMngXdgkVXC
XhFq/8WQY+ez5VpZXNeaPiq6kYLJVltjKcFSyKINb0z7jR11TRoUMgCCROqNTRj1Ioge
bFIgij/IcWleUZVIc5AAzrF6aTGsb0KZazH/SuDWF9ney307Bq33IbX5EBtRkMI9gyB6
qGjPZFjx22/bIPci/3TBH4ellfodo/asedKf/qTQgHpchootKBg6LXYooqWlaUvZc891
B7WZx+VhbBRwzzcPgyxD3qmPXeElCzODHijxlImM2GqTaf5VBrvz2K+nfa3qIi+XAqVy
rRaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759348238; x=1759953038;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:message-id:to:from:date:x-beenthere:x-gm-message-state
:sender:from:to:cc:subject:date:message-id:reply-to;
bh=H4e/lNCjHxSgb/BUtjsIOcLRiaHPjhz2f7MCWoAEWd8=;
b=T5ooLSjzP5Bikzs3uILIVmb7hNIwSYfCuynqCwzr++teVK0eeGJAdsCK3nUJz7qyyA
Ig6dMr8ptN0p0sAX9Igux/Z52CxY5hIh5VlXM/eq6LgmjkIdbYyJ1FNALZCaFG+6VPz3
Pex8htwgqujFpPqV61hESn0LWEsAxZmcXlF7Iim5kgSoVKRqu0aIM9oU0KE65zAloPQr
jbZ3A5C4r0lD2pdwbB47COdD/+UfG9dy9xqjSeOwOD0uGq97MTkQ7tQnNRDFPPxf1YUf
1WezUsqaE+B6Gxt9aZUSk/oEBcTbf8Jjj8ZMLsU3juQ+Cff9v408+i/qijradVk3VIBg
HFwA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXNSx0MHED2sVUFBKo3cXlbK1K+Jex6SuCaIskDnLli4/KhwPjXVozVL6traAEaHzGySDmXTziwxGII@gnusha.org
X-Gm-Message-State: AOJu0YyZ0ed8/7SO6HAXahzzSM0//lb5LVwRuPAwwKzVlZC+8Gz5pAea
ZP5m2F2oUcxUJWuJx1DMWAg8yOBY0yQQC9vgeXrZ0EDsdN7+50TEBedG
X-Google-Smtp-Source: AGHT+IE1bS9uqKCFlbe2WgbdUP4y/rsV4SQZW6kNi/091xHhoZaaFNOySpVTmmw6r3e2Ll9nVCXIlg==
X-Received: by 2002:a05:6214:b62:b0:78f:62ef:5a50 with SMTP id 6a1803df08f44-873a5d20844mr65251566d6.42.1759348237769;
Wed, 01 Oct 2025 12:50:37 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5Xu2ijPwnInpXKDH6+xG0X84ThmDdyU1H8ovERiP9nDQ=="
Received: by 2002:a05:6214:881:b0:783:6e2:3e57 with SMTP id
6a1803df08f44-878a187904bls4361706d6.0.-pod-prod-08-us; Wed, 01 Oct 2025
12:50:32 -0700 (PDT)
X-Received: by 2002:a05:620a:4722:b0:866:73f7:2589 with SMTP id af79cd13be357-873762e0a59mr679364485a.51.1759348232654;
Wed, 01 Oct 2025 12:50:32 -0700 (PDT)
Received: by 2002:a05:690c:62c4:b0:720:768:1935 with SMTP id 00721157ae682-77f6fbf5cc4ms7b3;
Wed, 1 Oct 2025 07:24:52 -0700 (PDT)
X-Received: by 2002:a05:690c:4c8b:b0:767:4209:b486 with SMTP id 00721157ae682-77f6f39e2a2mr43434797b3.30.1759328691218;
Wed, 01 Oct 2025 07:24:51 -0700 (PDT)
Date: Wed, 1 Oct 2025 07:24:50 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0f6c92cc-e922-4d9f-9fdf-69384dcc4086n@googlegroups.com>
Subject: [bitcoindev] On (in)ability to embed data into Schnorr
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_126442_663939594.1759328690860"
X-Original-Sender: ekaggata@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)
------=_Part_126442_663939594.1759328690860
Content-Type: multipart/alternative;
boundary="----=_Part_126443_1781324974.1759328690860"
------=_Part_126443_1781324974.1759328690860
Content-Type: text/plain; charset="UTF-8"
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.
------=_Part_126443_1781324974.1759328690860
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi all,<div><br /></div><div>https://github.com/AdamISZ/schnorr-unembeddabi=
lity/</div><div><br /></div><div>Here I'm analyzing whether the following s=
tatement is true: "if you can embed data into a (P, R, s) tuple (Schnorr pu=
bkey and signature, BIP340 style), without grinding or using a sidechannel =
to "inform" the reader, you must be leaking your private key".</div><div><b=
r /></div><div>See the abstract for a slightly more fleshed out context.</d=
iv><div><br /></div><div>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.</div><div><br /></div><div>(To emph=
asize, this is different to the earlier observations (including by me!) tha=
t 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*).</div><div><br /></div><di=
v>However I still am probably in the large majority that thinks it's appall=
ing to imagine a sig attached to every pubkey onchain.</div><div><br /></di=
v><div>Either way, I found it very interesting! Perhaps others will find th=
e analysis valuable.</div><div><br /></div><div>Feedback (especially of the=
"that's wrong/that's not meaningful" variety) appreciated.</div><div><br /=
></div><div>Regards,</div><div>AdamISZ/waxwing</div><div><br /></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/0f6c92cc-e922-4d9f-9fdf-69384dcc4086n%40googlegroups.com</a>.<br />
------=_Part_126443_1781324974.1759328690860--
------=_Part_126442_663939594.1759328690860--
|
