public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: waxwing/ AdamISZ <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Adaptor generalisation
Date: Wed, 9 Oct 2024 09:32:28 -0700 (PDT)	[thread overview]
Message-ID: <05f15314-f7b0-4b6e-8767-1399d7b9a100n@googlegroups.com> (raw)


[-- 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 --]

                 reply	other threads:[~2024-10-09 16:35 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=05f15314-f7b0-4b6e-8767-1399d7b9a100n@googlegroups.com \
    --to=ekaggata@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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