Date: Fri, 28 Apr 2023 18:13:03 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <Vv-Zz519CQs1JkS8NgeHfI-KGaYelNTxKMikPxdeIRiELmPKlT80g_-BzDgBvpm9MMIr-BRrSyGePC-HFR18QU4uzC0rPJdMzO_hlkUhUaM=@protonmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] On adaptor security (in protocols)
Precedence: list

Hi list,
I was motivated to look more carefully at the question of the security of u=
sing signature adaptors after recently getting quite enthused about the ide=
a of using adaptors across N signing sessions to do a kind of multiparty sw=
ap. But of course security analysis is also much more important for the bas=
e case of 2 party swapping, which is of .. some considerable practical impo=
rtance :)

There is work (referenced in Section 3 here) that's pretty substantial on "=
how secure are adaptors" (think in terms of security reductions) already fr=
om I guess the 2019-2021 period. But I wanted to get into scenarios of mult=
iple 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 - he=
nce (a) me posting it here and (b) putting the paper on github so people ca=
n 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 ses=
sions, 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 irrelevan=
t 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 h=
ave to say about security reductions for this primitive in the case of mult=
iple concurrent signing sessions (which of course has been analyzed very ca=
refully already for base MuSig(2)).

Cheers,
AdamISZ/waxwing


Sent with Proton Mail secure email.