Delivery-date: Wed, 09 Oct 2024 09:35:50 -0700
Sender: bitcoindev@googlegroups.com
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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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&quot; 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--