From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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
Hi list,
I wrote a post about generalisation of the concept = of adaptor signatures here:

https://reyify.com/b= log/adaptors-generalised/

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?"

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!

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 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.
=

To summarize the post for the time constrained:=

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.

=
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).

=
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.

Ch= eers,
AdamISZ/waxwing

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/05f15314-f7b0-4b6e-8767-1399d7b9a100n%40googlegroups.com.=
------=_Part_57763_2062346844.1728491548398-- ------=_Part_57762_1942447.1728491548398--