* [bitcoin-dev] On adaptor security (in protocols)
@ 2023-04-28 18:13 AdamISZ
2023-05-01 4:23 ` Lloyd Fournier
0 siblings, 1 reply; 8+ messages in thread
From: AdamISZ @ 2023-04-28 18:13 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Hi list,
I was motivated to look more carefully at the question of the security of using signature adaptors after recently getting quite enthused about the idea of using adaptors across N signing sessions to do a kind of multiparty swap. But of course security analysis is also much more important for the base case of 2 party swapping, which is of .. some considerable practical importance :)
There is work (referenced in Section 3 here) that's pretty substantial on "how secure are adaptors" (think in terms of security reductions) already from I guess the 2019-2021 period. But I wanted to get into scenarios of multiple adaptors at once or multiple signing sessions at once with the *same* adaptor (as mentioned above, probably this is the most important scenario).
To be clear this is the work of an amateur and is currently unreviewed - hence (a) me posting it here and (b) putting the paper on github so people can easily add specific corrections or comments if they like:
https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf
I'll note that I did the analysis only around MuSig, not MuSig2.
The penultimate ("third case"), that as mentioned, of "multiple signing sessions, same adaptor" proved to be the most interesting: in trying to reduce this to ECDLP I found an issue around sequencing. It may just be irrelevant but I'd be curious to hear what others think about that.
If nothing else, I'd be very interested to hear what experts in the field have to say about security reductions for this primitive in the case of multiple concurrent signing sessions (which of course has been analyzed very carefully already for base MuSig(2)).
Cheers,
AdamISZ/waxwing
Sent with Proton Mail secure email.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-04-28 18:13 [bitcoin-dev] On adaptor security (in protocols) AdamISZ @ 2023-05-01 4:23 ` Lloyd Fournier 2023-05-01 18:37 ` AdamISZ 0 siblings, 1 reply; 8+ messages in thread From: Lloyd Fournier @ 2023-05-01 4:23 UTC (permalink / raw) To: AdamISZ, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3706 bytes --] Hi waxwing, I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. I haven't read the proofs in detail but I am optimistic about your approach. One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure. Cheers, LL On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi list, > I was motivated to look more carefully at the question of the security of > using signature adaptors after recently getting quite enthused about the > idea of using adaptors across N signing sessions to do a kind of multiparty > swap. But of course security analysis is also much more important for the > base case of 2 party swapping, which is of .. some considerable practical > importance :) > > There is work (referenced in Section 3 here) that's pretty substantial on > "how secure are adaptors" (think in terms of security reductions) already > from I guess the 2019-2021 period. But I wanted to get into scenarios of > multiple adaptors at once or multiple signing sessions at once with the > *same* adaptor (as mentioned above, probably this is the most important > scenario). > > To be clear this is the work of an amateur and is currently unreviewed - > hence (a) me posting it here and (b) putting the paper on github so people > can easily add specific corrections or comments if they like: > > https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf > > I'll note that I did the analysis only around MuSig, not MuSig2. > > The penultimate ("third case"), that as mentioned, of "multiple signing > sessions, same adaptor" proved to be the most interesting: in trying to > reduce this to ECDLP I found an issue around sequencing. It may just be > irrelevant but I'd be curious to hear what others think about that. > > If nothing else, I'd be very interested to hear what experts in the field > have to say about security reductions for this primitive in the case of > multiple concurrent signing sessions (which of course has been analyzed > very carefully already for base MuSig(2)). > > Cheers, > AdamISZ/waxwing > > > > > Sent with Proton Mail secure email. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 4578 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-01 4:23 ` Lloyd Fournier @ 2023-05-01 18:37 ` AdamISZ 2023-05-03 12:58 ` AdamISZ 2023-05-08 4:37 ` Lloyd Fournier 0 siblings, 2 replies; 8+ messages in thread From: AdamISZ @ 2023-05-01 18:37 UTC (permalink / raw) To: Lloyd Fournier, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7493 bytes --] Hi Lloyd, thanks for taking a look. > I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. I'm struggling with this one - say I hold privkey x for pubkey X. And I publish adaptor for a point Y (DL y) for message m, like: s' = k - y + H(R|X|m)x with k the nonce and R the nonce point. And to get the basics clear first, if I publish s = k + H(R|X|m)x then of course the secret y is revealed. What do you mean in saying "any signature on m that is published reveals y"? Clearly you don't mean any signature on any key (i.e. not the key X). But I also can't parse it if you mean "any signature on m using key X", because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' as defined above, right? I think the point of confusion is maybe about the DLC construct? I referenced that in Section 4.2, parenthetically, because it's analogous in one sense - in MuSig(2) you're fixing R via a negotiation, whereas in Dryja's construct you're fixing R "by definition". When I was talking about single key Schnorr, I was saying that's what's missing, and thereby making them useless. I think I must have missed some implicit concept in your argument otherwise? > I haven't read the proofs in detail but I am optimistic about your approach Appreciate it, but I fear the optimism is misplaced; as you can see from some notes I made in Issue 1, I think I had a pretty substantially invalid line of reasoning in those proof. Probably I need to revert to the forking lemma style arguments that you and Aumayr et al (and some others) took. I also am revisiting a clearer definition of what security threats need to be addressed. It all seems very nuanced. But hey, that's why I published it and asked for feedback - if nothing else it made *me* think more carefully :) > One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure. Appreciate these thoughts. In particular your point about "generalization of tweaking" is clearly important, I bet other people have thought about it before me. Btw are there any papers on tweaking in general? I'm suddenly reminded of Poelstra's paper on taproot itself, which istr was an entirely different approach. Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Sunday, April 30th, 2023 at 22:23, Lloyd Fournier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi waxwing, > > I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. > > I haven't read the proofs in detail but I am optimistic about your approach. One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure. > > Cheers, > > LL > > On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hi list, >> I was motivated to look more carefully at the question of the security of using signature adaptors after recently getting quite enthused about the idea of using adaptors across N signing sessions to do a kind of multiparty swap. But of course security analysis is also much more important for the base case of 2 party swapping, which is of .. some considerable practical importance :) >> >> There is work (referenced in Section 3 here) that's pretty substantial on "how secure are adaptors" (think in terms of security reductions) already from I guess the 2019-2021 period. But I wanted to get into scenarios of multiple adaptors at once or multiple signing sessions at once with the *same* adaptor (as mentioned above, probably this is the most important scenario). >> >> To be clear this is the work of an amateur and is currently unreviewed - hence (a) me posting it here and (b) putting the paper on github so people can easily add specific corrections or comments if they like: >> >> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf >> >> I'll note that I did the analysis only around MuSig, not MuSig2. >> >> The penultimate ("third case"), that as mentioned, of "multiple signing sessions, same adaptor" proved to be the most interesting: in trying to reduce this to ECDLP I found an issue around sequencing. It may just be irrelevant but I'd be curious to hear what others think about that. >> >> If nothing else, I'd be very interested to hear what experts in the field have to say about security reductions for this primitive in the case of multiple concurrent signing sessions (which of course has been analyzed very carefully already for base MuSig(2)). >> >> Cheers, >> AdamISZ/waxwing >> >> Sent with Proton Mail secure email. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 9651 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-01 18:37 ` AdamISZ @ 2023-05-03 12:58 ` AdamISZ 2023-05-08 4:37 ` Lloyd Fournier 1 sibling, 0 replies; 8+ messages in thread From: AdamISZ @ 2023-05-03 12:58 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 8999 bytes --] Hi Lloyd and list, While on the road and re-downloading the papers, I realised there is a "new" paper published December 2022 by Wei Dai, Okamoto and Yamamoto on this same topic: https://eprint.iacr.org/2022/1687 and, strikingly, it focuses on the exact same point I made here in Section 3 - namely that the aEUF-CMA definition of the Aumayr paper doesn't address the possibility of multiple-adaptors-on-the-same-message-at-once. A pretty big facepalm moment that I didn't bother to search carefully enough to find that! Also it's cool that such renowned cryptographers are turning their heads towards this subject :) It does have a nice illustration of why that definition (which as you know has been reused by other researchers) is insufficient, by making up a malicious version of the "preSign" (i.e. adaptor-sign) algorithm which leaks an arbitrary signature after two calls, while it still fits the definition of aEUF-CMA! The paper has a *lot* of meat in terms of security definitions (only had a brief chance to read parts of it, as I'm on the road, so this is high level vague perspective), but afaict it is not actually attempting to rewrite reductions(?), so perhaps more work is needed on that(?). Cheers,Adam Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Monday, May 1st, 2023 at 12:37, AdamISZ via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi Lloyd, > thanks for taking a look. > >> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. > > I'm struggling with this one - say I hold privkey x for pubkey X. And I publish adaptor for a point Y (DL y) for message m, like: s' = k - y + H(R|X|m)x with k the nonce and R the nonce point. > > And to get the basics clear first, if I publish s = k + H(R|X|m)x then of course the secret y is revealed. > > What do you mean in saying "any signature on m that is published reveals y"? Clearly you don't mean any signature on any key (i.e. not the key X). But I also can't parse it if you mean "any signature on m using key X", because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' as defined above, right? > > I think the point of confusion is maybe about the DLC construct? I referenced that in Section 4.2, parenthetically, because it's analogous in one sense - in MuSig(2) you're fixing R via a negotiation, whereas in Dryja's construct you're fixing R "by definition". When I was talking about single key Schnorr, I was saying that's what's missing, and thereby making them useless. > > I think I must have missed some implicit concept in your argument otherwise? > >> I haven't read the proofs in detail but I am optimistic about your approach > > Appreciate it, but I fear the optimism is misplaced; as you can see from some notes I made in Issue 1, I think I had a pretty substantially invalid line of reasoning in those proof. Probably I need to revert to the forking lemma style arguments that you and Aumayr et al (and some others) took. I also am revisiting a clearer definition of what security threats need to be addressed. It all seems very nuanced. > > But hey, that's why I published it and asked for feedback - if nothing else it made *me* think more carefully :) > >> One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure. > Appreciate these thoughts. In particular your point about "generalization of tweaking" is clearly important, I bet other people have thought about it before me. Btw are there any papers on tweaking in general? I'm suddenly reminded of Poelstra's paper on taproot itself, which istr was an entirely different approach. > > Sent with [Proton Mail](https://proton.me/) secure email. > > ------- Original Message ------- > On Sunday, April 30th, 2023 at 22:23, Lloyd Fournier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Hi waxwing, >> >> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. >> >> I haven't read the proofs in detail but I am optimistic about your approach. One thing I was considering while reading is that you could make a general proof against all secure Schnorr signing scheme in the ROM by simply extending the ROM forwarding approach from Aumayer et al to all "tweak" operations on the elements that go into the Schnorr challenge hash i.e. the public key and the nonce. After all whether it's MuSig2, MuSig, FROST they all must call some RO. I think we can prove that if we apply any bijective map to the (X,R) tuple before they go into the challenge hash function then any Schnorr-like scheme that was secure before will be secure when bip32/TR tweaking (i.e. tweaking X) and adaptor tweaking (tweaking R) is applied to it. This would be cool because then we could prove all these variants secure for all schemes past and present in one go. I haven't got a concrete approach but the proofs I've looked at all seem to share this structure. >> >> Cheers, >> >> LL >> >> On Sun, 30 Apr 2023 at 00:20, AdamISZ via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> Hi list, >>> I was motivated to look more carefully at the question of the security of using signature adaptors after recently getting quite enthused about the idea of using adaptors across N signing sessions to do a kind of multiparty swap. But of course security analysis is also much more important for the base case of 2 party swapping, which is of .. some considerable practical importance :) >>> >>> There is work (referenced in Section 3 here) that's pretty substantial on "how secure are adaptors" (think in terms of security reductions) already from I guess the 2019-2021 period. But I wanted to get into scenarios of multiple adaptors at once or multiple signing sessions at once with the *same* adaptor (as mentioned above, probably this is the most important scenario). >>> >>> To be clear this is the work of an amateur and is currently unreviewed - hence (a) me posting it here and (b) putting the paper on github so people can easily add specific corrections or comments if they like: >>> >>> https://github.com/AdamISZ/AdaptorSecurityDoc/blob/main/adaptorsecurity.pdf >>> >>> I'll note that I did the analysis only around MuSig, not MuSig2. >>> >>> The penultimate ("third case"), that as mentioned, of "multiple signing sessions, same adaptor" proved to be the most interesting: in trying to reduce this to ECDLP I found an issue around sequencing. It may just be irrelevant but I'd be curious to hear what others think about that. >>> >>> If nothing else, I'd be very interested to hear what experts in the field have to say about security reductions for this primitive in the case of multiple concurrent signing sessions (which of course has been analyzed very carefully already for base MuSig(2)). >>> >>> Cheers, >>> AdamISZ/waxwing >>> >>> Sent with Proton Mail secure email. >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 12180 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-01 18:37 ` AdamISZ 2023-05-03 12:58 ` AdamISZ @ 2023-05-08 4:37 ` Lloyd Fournier 2023-05-11 5:12 ` AdamISZ 1 sibling, 1 reply; 8+ messages in thread From: Lloyd Fournier @ 2023-05-08 4:37 UTC (permalink / raw) To: AdamISZ; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2531 bytes --] Hi Waxwing, On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@protonmail•com> wrote: > Hi Lloyd, > thanks for taking a look. > > > I think your view of the uselessness of single signer adaptors is too > pessimistic. The claim you make is that they "don't provide a way to create > enforcement that the publication of signature on a pre-defined message will > reveal a secret'' and so are useless. I think this is wrong. If I hold a > secret key for X and create a signature adaptor with some encryption key Y > with message m and do not create any further signatures (adaptor or > otherwise) on m, then any signature on m that is published necessarily > reveals the secret on Y to me. This is very useful and has already been > used for years by DLCs in production. > > I'm struggling with this one - say I hold privkey x for pubkey X. And I > publish adaptor for a point Y (DL y) for message m, like: s' = k - y + > H(R|X|m)x with k the nonce and R the nonce point. > > And to get the basics clear first, if I publish s = k + H(R|X|m)x then of > course the secret y is revealed. > > What do you mean in saying "any signature on m that is published reveals > y"? Clearly you don't mean any signature on any key (i.e. not the key X). > But I also can't parse it if you mean "any signature on m using key X", > because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no > algebraic relationship to the adaptor s' as defined above, right? > Yes but suppose you do *not* create another signature adaptor or otherwise on m. Since you've only generated one adaptor signature on m and no other signatures on m there is no possibility that a signature on m that appears under your key would not reveal y to you. This is an useful property in theory and in practice. > > I think the point of confusion is maybe about the DLC construct? I > referenced that in Section 4.2, parenthetically, because it's analogous in > one sense - in MuSig(2) you're fixing R via a negotiation, whereas in > Dryja's construct you're fixing R "by definition". When I was talking about > single key Schnorr, I was saying that's what's missing, and thereby making > them useless. > > I was not referencing the DLC oracle attestation protocol - I am pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for the transaction signatures. There are even channel implementations using them as well as atomic swaps doing this iirc. It's a pretty useful thing! Cheers, LL [-- Attachment #2: Type: text/html, Size: 3419 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-08 4:37 ` Lloyd Fournier @ 2023-05-11 5:12 ` AdamISZ 2023-05-11 11:41 ` Lloyd Fournier 0 siblings, 1 reply; 8+ messages in thread From: AdamISZ @ 2023-05-11 5:12 UTC (permalink / raw) To: Lloyd Fournier, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4532 bytes --] Hi Lloyd, > Yes but suppose you do *not* create another signature adaptor or otherwise on m. Since you've only generated one adaptor signature on m and no other signatures on m there is no possibility that a signature on m that appears under your key would not reveal y to you. This is an useful property in theory and in practice. Ah yes, this is a pretty big error on my part! Thanks for walking it through. It's where this is analogous to asymmetric encryption. I remember you framing it like that, in terms of asymmetric encryption (but with the one-time, a bit like symmetric, twist), in your paper. I should have re-read it a lot more thoroughly! :) I must have had this misconception floating around in my head about adaptors for years. It's interesting that it didn't help choosing the framing : s' = k - t +H(R|P|m)x instead of s' = k + H(R+T|P|m)x although, as I noted there, they're equivalent (indeed, the former framing was also used in e.g. the description of the atomic swap in the scriptless-scripts writeups repo). But in the latter framing it's much more obvious that you can do this, given that you can just plug T into the hash directly. A sidebar, but it immediately brings it to mind: the canonical adaptor based swap, you can do it with only one half being multisig like this, right? Alice can encrypt the single-key signature for her payment to Bob, with the encryption key being T= sG, where s is the partial signature of Bob, on the payout from a multisig, to Alice. That way Bob only gets his money in the single sig (A->B) tx, if he reveals his partial sig on the multisig. I don't think it's of practical interest (1 multisig instead of 2? meh), but .. I don't see anywhere that potential variant being written down? Is there some obvious flaw with that? Cheers, waxwing/AdamISZ Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Hi Waxwing, > > On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@protonmail•com> wrote: > >> Hi Lloyd, >> thanks for taking a look. >> >>> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. >> >> I'm struggling with this one - say I hold privkey x for pubkey X. And I publish adaptor for a point Y (DL y) for message m, like: s' = k - y + H(R|X|m)x with k the nonce and R the nonce point. >> >> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of course the secret y is revealed. >> >> What do you mean in saying "any signature on m that is published reveals y"? Clearly you don't mean any signature on any key (i.e. not the key X). But I also can't parse it if you mean "any signature on m using key X", because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' as defined above, right? > > Yes but suppose you do *not* create another signature adaptor or otherwise on m. Since you've only generated one adaptor signature on m and no other signatures on m there is no possibility that a signature on m that appears under your key would not reveal y to you. This is an useful property in theory and in practice. > >> I think the point of confusion is maybe about the DLC construct? I referenced that in Section 4.2, parenthetically, because it's analogous in one sense - in MuSig(2) you're fixing R via a negotiation, whereas in Dryja's construct you're fixing R "by definition". When I was talking about single key Schnorr, I was saying that's what's missing, and thereby making them useless. > > I was not referencing the DLC oracle attestation protocol - I am pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for the transaction signatures. There are even channel implementations using them as well as atomic swaps doing this iirc. It's a pretty useful thing! > > Cheers, > > LL [-- Attachment #2: Type: text/html, Size: 7067 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-11 5:12 ` AdamISZ @ 2023-05-11 11:41 ` Lloyd Fournier 2023-05-14 8:37 ` AdamISZ 0 siblings, 1 reply; 8+ messages in thread From: Lloyd Fournier @ 2023-05-11 11:41 UTC (permalink / raw) To: AdamISZ; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4102 bytes --] On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ@protonmail•com> wrote: > > A sidebar, but it immediately brings it to mind: the canonical adaptor > based swap, you can do it with only one half being multisig like this, > right? Alice can encrypt the single-key signature for her payment to Bob, > with the encryption key being T= sG, where s is the partial signature of > Bob, on the payout from a multisig, to Alice. That way Bob only gets his > money in the single sig (A->B) tx, if he reveals his partial sig on the > multisig. I don't think it's of practical interest (1 multisig instead of > 2? meh), but .. I don't see anywhere that potential variant being written > down? Is there some obvious flaw with that? > I think the problem is that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. I think you always need a multisig in these kinds of situations but it need not be a key aggregated multisig like MuSig -- this was the point I wanted to make (in retrospect clumsily). I don't think I can name a useful use of a single signer adaptor signature in Bitcoin at least not without some kind of other spending constraint. So your intuitive point holds in practice most of the time. LL Cheers, > waxwing/AdamISZ > > Sent with Proton Mail <https://proton.me/> secure email. > > ------- Original Message ------- > On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > > Hi Waxwing, > > On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@protonmail•com> wrote: > >> Hi Lloyd, >> thanks for taking a look. >> >> > I think your view of the uselessness of single signer adaptors is too >> pessimistic. The claim you make is that they "don't provide a way to create >> enforcement that the publication of signature on a pre-defined message will >> reveal a secret'' and so are useless. I think this is wrong. If I hold a >> secret key for X and create a signature adaptor with some encryption key Y >> with message m and do not create any further signatures (adaptor or >> otherwise) on m, then any signature on m that is published necessarily >> reveals the secret on Y to me. This is very useful and has already been >> used for years by DLCs in production. >> >> I'm struggling with this one - say I hold privkey x for pubkey X. And I >> publish adaptor for a point Y (DL y) for message m, like: s' = k - y + >> H(R|X|m)x with k the nonce and R the nonce point. >> >> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of >> course the secret y is revealed. >> >> What do you mean in saying "any signature on m that is published reveals >> y"? Clearly you don't mean any signature on any key (i.e. not the key X). >> But I also can't parse it if you mean "any signature on m using key X", >> because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no >> algebraic relationship to the adaptor s' as defined above, right? >> > > Yes but suppose you do *not* create another signature adaptor or otherwise > on m. Since you've only generated one adaptor signature on m and no other > signatures on m there is no possibility that a signature on m that appears > under your key would not reveal y to you. This is an useful property in > theory and in practice. > > >> I think the point of confusion is maybe about the DLC construct? I >> referenced that in Section 4.2, parenthetically, because it's analogous in >> one sense - in MuSig(2) you're fixing R via a negotiation, whereas in >> Dryja's construct you're fixing R "by definition". When I was talking about >> single key Schnorr, I was saying that's what's missing, and thereby making >> them useless. >> >> I was not referencing the DLC oracle attestation protocol - I am pointing > out that DLC client implementations have been using single signer adaptor > signatures as signature encryption in practice for years for the > transaction signatures. There are even channel implementations using them > as well as atomic swaps doing this iirc. It's a pretty useful thing! > > Cheers, > > LL > > > [-- Attachment #2: Type: text/html, Size: 6269 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] On adaptor security (in protocols) 2023-05-11 11:41 ` Lloyd Fournier @ 2023-05-14 8:37 ` AdamISZ 0 siblings, 0 replies; 8+ messages in thread From: AdamISZ @ 2023-05-14 8:37 UTC (permalink / raw) To: Lloyd Fournier, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 7758 bytes --] > I think the problem is that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. Indeed. Imagine forgetting that, couldn't be me :) > I think you always need a multisig in these kinds of situations but it need not be a key aggregated multisig like MuSig -- this was the point I wanted to make (in retrospect clumsily). I don't think I can name a useful use of a single signer adaptor signature in Bitcoin at least not without some kind of other spending constraint. So your intuitive point holds in practice most of the time. Indeed I do have a similar memory of earlier discussions/thoughts that: the finesse is that it only needs to be multisig, which is not the same as it needing to be musig, or let's say aggregated. The conversation has shifted over time because a lot of the first ideas (and papers) were pre-BIP340 activation and included ECDSA variants. A good example of the lack of clarity on this is the aforementioned Wei Dai paper, in which their base example is a swap without any multisig, thus ignoring the double spend issue (forgiveable, they are focused on different things in that paper). It's striking how unclear all this is (perhaps, just for me!) ... ... so let's see if I have it right: (1) - single key signature adaptor in isolation is basically useless, in a Bitcoin context (signature is on a utxo) ** (2) - single key signature adaptor in combination with another locking condition on the utxo, such as another pubkey lock (e.g. op_checksigadd/op_checkmultisig), is useful in swapping a signature for a secret, but it requires using the variant of the primitive in which the non-secret-owner is the one encrypting (i.e. asymmetric encryption analog), and the secret owner is giving the decryption. (3) - most natural scenario, using aggregated signature schemes like MuSig1/2, can allow the above, but can also allow the variant in which the secret owner starts by providing the encryption, and then at a later stage of the protocol, releases the decryption (this option is not available for (2), since the provision of an adaptor for my own signature does not force me, in that case to use the same R, and therefore a corresponding signature). (the canonical description in [1] for any reader who's not familiar, outlines this case). (the difference between (2) and (3) can maybe best be grokked as the choice between "I need any signature of yours - I can get one by decrypting it using my secret key, or you can just give me one" vs "I need a specific signature of yours, I'll get it when you decrypt, using your own secret, the other signature" - and here you see that the second one has a requirement that I can't let you use an alternate for the first signature, because then I get nothing.) ** But now I'm confused about your earlier reference to DLC implementations using single signer constructions in the previous mail (your phrase was "using single signer adaptor signatures as signature encryption in practice for years for the transaction signatures") - can you link me to something about that? I couldn't immediately find something in the DLC specs repo, though I'm probably just missing it. I'm just really interested to know if there's another functionality I'm missing here, (since you said it wasn't oracle attestation, that you meant). [1] https://github.com/BlockstreamResearch/scriptless-scripts/blob/master/md/atomic-swap.md#atomic-swaps-using-adaptor-signatures Cheers, AdamISZ/waxwing Sent with [Proton Mail](https://proton.me/) secure email. ------- Original Message ------- On Thursday, May 11th, 2023 at 12:41, Lloyd Fournier <lloyd.fourn@gmail•com> wrote: > On Thu, 11 May 2023 at 13:12, AdamISZ <AdamISZ@protonmail•com> wrote: > >> A sidebar, but it immediately brings it to mind: the canonical adaptor based swap, you can do it with only one half being multisig like this, right? Alice can encrypt the single-key signature for her payment to Bob, with the encryption key being T= sG, where s is the partial signature of Bob, on the payout from a multisig, to Alice. That way Bob only gets his money in the single sig (A->B) tx, if he reveals his partial sig on the multisig. I don't think it's of practical interest (1 multisig instead of 2? meh), but .. I don't see anywhere that potential variant being written down? Is there some obvious flaw with that? > > I think the problem is that Alice can still move the funds even if Bob decrypts and broadcasts by revealing s if she gets confirmed first. I think you always need a multisig in these kinds of situations but it need not be a key aggregated multisig like MuSig -- this was the point I wanted to make (in retrospect clumsily). I don't think I can name a useful use of a single signer adaptor signature in Bitcoin at least not without some kind of other spending constraint. So your intuitive point holds in practice most of the time. > > LL > >> Cheers, >> waxwing/AdamISZ >> >> Sent with [Proton Mail](https://proton.me/) secure email. >> >> ------- Original Message ------- >> On Monday, May 8th, 2023 at 05:37, Lloyd Fournier via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> Hi Waxwing, >>> >>> On Tue, 2 May 2023 at 02:37, AdamISZ <AdamISZ@protonmail•com> wrote: >>> >>>> Hi Lloyd, >>>> thanks for taking a look. >>>> >>>>> I think your view of the uselessness of single signer adaptors is too pessimistic. The claim you make is that they "don't provide a way to create enforcement that the publication of signature on a pre-defined message will reveal a secret'' and so are useless. I think this is wrong. If I hold a secret key for X and create a signature adaptor with some encryption key Y with message m and do not create any further signatures (adaptor or otherwise) on m, then any signature on m that is published necessarily reveals the secret on Y to me. This is very useful and has already been used for years by DLCs in production. >>>> >>>> I'm struggling with this one - say I hold privkey x for pubkey X. And I publish adaptor for a point Y (DL y) for message m, like: s' = k - y + H(R|X|m)x with k the nonce and R the nonce point. >>>> >>>> And to get the basics clear first, if I publish s = k + H(R|X|m)x then of course the secret y is revealed. >>>> >>>> What do you mean in saying "any signature on m that is published reveals y"? Clearly you don't mean any signature on any key (i.e. not the key X). But I also can't parse it if you mean "any signature on m using key X", because if I go ahead and publish s = k_2 + H(R_2|X|m)x, it has no algebraic relationship to the adaptor s' as defined above, right? >>> >>> Yes but suppose you do *not* create another signature adaptor or otherwise on m. Since you've only generated one adaptor signature on m and no other signatures on m there is no possibility that a signature on m that appears under your key would not reveal y to you. This is an useful property in theory and in practice. >>> >>>> I think the point of confusion is maybe about the DLC construct? I referenced that in Section 4.2, parenthetically, because it's analogous in one sense - in MuSig(2) you're fixing R via a negotiation, whereas in Dryja's construct you're fixing R "by definition". When I was talking about single key Schnorr, I was saying that's what's missing, and thereby making them useless. >>> >>> I was not referencing the DLC oracle attestation protocol - I am pointing out that DLC client implementations have been using single signer adaptor signatures as signature encryption in practice for years for the transaction signatures. There are even channel implementations using them as well as atomic swaps doing this iirc. It's a pretty useful thing! >>> >>> Cheers, >>> >>> LL [-- Attachment #2: Type: text/html, Size: 12376 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-05-14 8:38 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-28 18:13 [bitcoin-dev] On adaptor security (in protocols) AdamISZ 2023-05-01 4:23 ` Lloyd Fournier 2023-05-01 18:37 ` AdamISZ 2023-05-03 12:58 ` AdamISZ 2023-05-08 4:37 ` Lloyd Fournier 2023-05-11 5:12 ` AdamISZ 2023-05-11 11:41 ` Lloyd Fournier 2023-05-14 8:37 ` AdamISZ
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox