Re: [bitcoin-dev] On adaptor security (in protocols)

[AdamISZ via bitcoin-dev]

> 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  
wrote:

> On Thu, 11 May 2023 at 13:12, AdamISZ  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
>
>> 

Re: [bitcoin-dev] On adaptor security (in protocols)

[Lloyd Fournier via bitcoin-dev]

On Thu, 11 May 2023 at 13:12, AdamISZ  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  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  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
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On adaptor security (in protocols)

[AdamISZ via bitcoin-dev]

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 
 wrote:

> Hi Waxwing,
>
> On Tue, 2 May 2023 at 02:37, AdamISZ  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On adaptor security (in protocols)

[Lloyd Fournier via bitcoin-dev]

Hi Waxwing,

On Tue, 2 May 2023 at 02:37, AdamISZ  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On adaptor security (in protocols)

[AdamISZ via bitcoin-dev]

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

Re: [bitcoin-dev] On adaptor security (in protocols)

[AdamISZ via bitcoin-dev]

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 
 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 p

Re: [bitcoin-dev] On adaptor security (in protocols)

[Lloyd Fournier via bitcoin-dev]

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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev