BlockstreamResearch / scriptless-scripts

Documentation about scriptless scripts
159 stars 25 forks source link

MuSig2 Adaptor Signatures #23

Open jonasnick opened 3 years ago

jonasnick commented 3 years ago

Since MuSig2 is very similar to its predecessor, it's straightforward to use adaptor signatures as before. The version of adaptor signatures as used in the multi-hop locks (aka PTLCs) writeup is

s'G = RA + hash(P || R + T || m)P

where s' is a partial signature for aggregated pubkey P with partial nonce RA, aggregated nonce R and adaptor point T.

Note that this means that the adaptor point T must be determined before opening the commitments in MuSig1 (i.e. before round 2). Otherwise, an attacker can apply Wagner's algorithm by grinding T similar to how the attacker can grind m if it's not determined before the nonce exchange. MuSig2 solves the latter problem by using two nonces per participant. More specifically, let RA1, RA2 be Alice's and RB1, RB2 be Bob's nonces. Then b = hash(P, RA1 + RB1, RA2 + RB2, m) and Alice's "effective nonce" becomes RA = RA1 + b*RA2.

I suggest to add T to the input of the hash function used to compute b. Then the nonce exchange round is purely a preprocessing step that can happen before T is known. Similar to before the partial signature is s' where

b = hash(P, RA1 + RB1, RA2 + RB2, m, T)
RA = RA1 + b*RA2
s'G = RA + hash(P || R + T || m)P

If we treat T as an additional input in the second round of MuSig2, its security as a multisignature scheme would not be affected. Two relevant prerequisites of the ROM proof are met: first, if the forger closes a signing session with different T's then the b's will be different and second, the reduction can make a challenge query hash(P || R + T || m) from seeing just the inputs of the hash used to compute b.

A similarly appropriate variant can be obtained by computing b as hash(P, RA1 + RB1 + T, RA2 + RB2, m) which may compose better in nested MuSig2 (?).

burdges commented 3 years ago

It's fine so long as the verification works by revealing some DLOG like signatures do. I think adaptor signatures fit this requirement normally, well like you describe here. :)

If however one wants verification by anything more subtle like in implicit certificates then maybe the proof becomes more complex, but probably just towards the end, so maybe no big deal.