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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
Delivery-date: Wed, 09 Oct 2024 09:35:50 -0700
Received: from mail-pj1-f56.google.com ([209.85.216.56])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDI23FE35EIBBXHBTK4AMGQEL53SOIA@googlegroups.com>)
id 1syZfB-000224-N6
for bitcoindev@gnusha.org; Wed, 09 Oct 2024 09:35:50 -0700
Received: by mail-pj1-f56.google.com with SMTP id 98e67ed59e1d1-2e2a013a01bsf64391a91.0
for <bitcoindev@gnusha.org>; Wed, 09 Oct 2024 09:35:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1728491744; x=1729096544; 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=J9P4+gKZK6M0qMbzSmgCCiSTmgjB4B2h4Tfnci6Q2GU=;
b=ZfvJoK8EruAsf19mOlNkydnWn67HJs4oQIxmhppJOWHIe2ICJ/IBcpCnt2pvzoWHIt
yBJgzS3G2HqcW0i7WAaYB5t+bT4vYKtcrQKvXEgPaKYUJC79ijBnt2ZQr633cvNeWwGx
kLeeAqj3pmGKFLksfwGhVwjC9nHDkQYklwgCDm39VhUdWOEoTUs5aOzZMe9B6yiZwGv1
SPLbgB3tTRJn6gFhmfcKVg3/pqNMR/RS1DDFvLITGTkTowNHGEOIZ7Vm0wvZvRnrxFI3
py0QS3IaY/pNDWIRTrKbLwDOD8kWMtmnZhzfCajEIPNthl1eG96lhIX5//JSWqm6GzLm
EUoQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1728491744; x=1729096544; 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=J9P4+gKZK6M0qMbzSmgCCiSTmgjB4B2h4Tfnci6Q2GU=;
b=a+BO/RMJgLDwWb+4DDXJVLsQL7WiBVBvylJPmFOJf9La1CwSWNlprR55P3E8FLCQt4
S5+6IwUYQAOjE2DwIJdcDDgCDESh/VZBtGYlT36wUC+UnXz8vht/Fde1V3Of8W1kPLLT
8/N8/pdQuBJGFDhLRo/Zs3gWZRWlx85H+GMvqZGuZ8QzjXFCbzg7tn4fxMOJzatfgU6o
oYpx6P0CxnFHe50ADj1ikiH4QOEXq4lyYFNPlNUHSCXohjAHOdwIgwx4oOzuPN8m1jLO
U30ZC7SMKrMCqCA6+WszKNmX/1kzIAN9m1v8BQ6+fywQB8Izp/ZluSeDxVA3eCvBGuWY
FwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1728491744; x=1729096544;
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=J9P4+gKZK6M0qMbzSmgCCiSTmgjB4B2h4Tfnci6Q2GU=;
b=qiIhSZ/X5etw92RH+FHfx71SX+vAPuMb6YbLM805RkDrDU3GlysUp7K9zF7Y7msyEB
NuvgMmRl30euyZMou30NcbUEMItwQKztfUY5Iir3a+6N6xstsuRhzK1iZOLKw+9ESfT6
OETUW3I1igDS+srXGeBTV6J3bT7cdiEVcwrQ8cDKyt3aihOrNRpPMGRT1dK1NAmfr4oP
EJfiqBh7rP6r8Ma3VQuVDEjSJlfuN3iVYl0hMsW7DhSpctKHzkbTVhePLfdm3Zn3qNxe
G5JdKP/7CHZRup/JG75atkWOaGugcvdvXyjQqzvtPrR2bM3frMLXyJSXfW9Kc512MG9C
6+7Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUB81G+4pZEdVURzfmyTeq9+OVRLmFVxKXvmvkWZzrZDrxyZudIJ4Z2zNWOuxjySvF1it7xLC2j1LW+@gnusha.org
X-Gm-Message-State: AOJu0YzrGkC/seQR0rhOz/nF4VXlvDi/Z7OQSJrodz7PBKjU/gJzN0Mj
RN9e015rJfKbK0uIvuwsa9P3VQQlWcJHOA7VfJP0KQA6Lz3dhV8m
X-Google-Smtp-Source: AGHT+IEADsrRmyxwY/2CoSa80gMYDNYLhcCsnuuY407E892vXcYL6KsYypZ/SE9Qvi6mw1cTv7YEpg==
X-Received: by 2002:a17:90a:d787:b0:2d8:8509:85cd with SMTP id 98e67ed59e1d1-2e2c63d414fmr555573a91.40.1728491743756;
Wed, 09 Oct 2024 09:35:43 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a17:90a:c291:b0:2e2:c774:2b42 with SMTP id
98e67ed59e1d1-2e2c81bd3b8ls30852a91.0.-pod-prod-09-us; Wed, 09 Oct 2024
09:35:40 -0700 (PDT)
X-Received: by 2002:a05:690c:93:b0:6e2:b537:3085 with SMTP id 00721157ae682-6e322439479mr27572387b3.34.1728491740161;
Wed, 09 Oct 2024 09:35:40 -0700 (PDT)
Received: by 2002:a05:690c:3411:b0:6dd:c9c1:7a16 with SMTP id 00721157ae682-6e31ec9542fms7b3;
Wed, 9 Oct 2024 09:32:30 -0700 (PDT)
X-Received: by 2002:a05:690c:6813:b0:6e3:23d9:ccd4 with SMTP id 00721157ae682-6e32f274602mr2192517b3.21.1728491548661;
Wed, 09 Oct 2024 09:32:28 -0700 (PDT)
Date: Wed, 9 Oct 2024 09:32:28 -0700 (PDT)
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <05f15314-f7b0-4b6e-8767-1399d7b9a100n@googlegroups.com>
Subject: [bitcoindev] Adaptor generalisation
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_57762_1942447.1728491548398"
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_57762_1942447.1728491548398
Content-Type: multipart/alternative;
boundary="----=_Part_57763_2062346844.1728491548398"
------=_Part_57763_2062346844.1728491548398
Content-Type: text/plain; charset="UTF-8"
Hi list,
I wrote a post about generalisation of the concept of adaptor signatures
here:
https://reyify.com/blog/adaptors-generalised/
Motivating Q: "Is there a value in being able to verify a statement that is
not limited to the default secp256k1 generator G, on chain?"
I think the natural answer is twofold: yes that could definitely be useful
for various ZKP constructions, and also: it's not possible, which makes it
a lot less interesting!
The paper is basically an investigation into whether the concept of
adaptors could somehow "sneak in" some kind of such verification via the
backdoor, so to speak.
The conclusion is that *something* like this seems to be possible: it's a
2-party protocol in which A convinces B that if a BIP340 signature is
published, then a DLEQ statement (which is a statement with two bases, G
and something else) is true. It's interactive: A needs to give B an adaptor
first, which *doesn't* prove the DLEQ relationship in itself.
To summarize the post for the time constrained:
the first half is looking at one way of generalising; for multi base single
statements ("proof of representation" if that phrase is familiar). I don't
pursue that into anything concrete for now, so feel free to skip it unless
that's interesting in itself.
the second half focuses on the idea that, by embedding 1 or 2 curve points
into the transaction message, you could craft a BIP340 signature such that
a valid adaptor on it will satisfy the other party that: *if* the signature
is published on chain, it proves the DLEQ relationship (if not, the adaptor
could have been forged, as argued in detail).
Would love to extend this all the way to generalised sigma protocols using
the idea of the first half of the blog post, in combination with the
second, but it seems very unclear.
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/05f15314-f7b0-4b6e-8767-1399d7b9a100n%40googlegroups.com.
------=_Part_57763_2062346844.1728491548398
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div>Hi list,</div><div>I wrote a post about generalisation of the concept =
of adaptor signatures here:</div><div><br /></div><div>https://reyify.com/b=
log/adaptors-generalised/</div><div><br /></div><div>Motivating Q: "Is ther=
e a value in being able to verify a statement that is not limited to the de=
fault secp256k1 generator G, on chain?"</div><div><br /></div><div>I think =
the natural answer is twofold: yes that could definitely be useful for vari=
ous ZKP constructions, and also: it's not possible, which makes it a lot le=
ss interesting!<br /></div><div><br /></div><div>The paper is basically an =
investigation into whether the concept of adaptors could somehow "sneak in"=
some kind of such verification via the backdoor, so to speak.</div><div><b=
r /></div><div>The conclusion is that *something* like this seems to be pos=
sible: it's a 2-party protocol in which A convinces B that if a BIP340 sign=
ature is published, then a DLEQ statement (which is a statement with two ba=
ses, G and something else) is true. It's interactive: A needs to give B an =
adaptor first, which *doesn't* prove the DLEQ relationship in itself.<br />=
</div><div><br /></div><div>To summarize the post for the time constrained:=
</div><div><br /></div><div>the first half is looking at one way of general=
ising; for multi base single statements ("proof of representation" if that =
phrase is familiar). I don't pursue that into anything concrete for now, so=
feel free to skip it unless that's interesting in itself.</div><div><br />=
</div><div>the second half focuses on the idea that, by embedding 1 or 2 cu=
rve points into the transaction message, you could craft a BIP340 signature=
such that a valid adaptor on it will satisfy the other party that: *if* th=
e signature is published on chain, it proves the DLEQ relationship (if not,=
the adaptor could have been forged, as argued in detail).</div><div><br />=
</div><div>Would love to extend this all the way to generalised sigma proto=
cols using the idea of the first half of the blog post, in combination with=
the second, but it seems very unclear.<br /></div><div><br /></div><div>Ch=
eers,</div><div>AdamISZ/waxwing<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 on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/05f15314-f7b0-4b6e-8767-1399d7b9a100n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/05f15314-f7b0-4b6e-8767-1399d7b9a100n%40googlegroups.com</a>.=
<br />
------=_Part_57763_2062346844.1728491548398--
------=_Part_57762_1942447.1728491548398--
|
