Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MuSig2 Adaptor Signatures #23

Open
jonasnick opened this issue Oct 14, 2020 · 1 comment · May be fixed by #24
Open

MuSig2 Adaptor Signatures #23

jonasnick opened this issue Oct 14, 2020 · 1 comment · May be fixed by #24

Comments

@jonasnick
Copy link
Collaborator

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

burdges commented Oct 15, 2020

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.

@jonasnick jonasnick linked a pull request Dec 18, 2020 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants