public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [bitcoindev] Adaptor generalisation
@ 2024-10-09 16:32 waxwing/ AdamISZ
  0 siblings, 0 replies; only message in thread
From: waxwing/ AdamISZ @ 2024-10-09 16:32 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 2237 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 2796 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-10-09 16:35 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-10-09 16:32 [bitcoindev] Adaptor generalisation waxwing/ AdamISZ

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox