-
Notifications
You must be signed in to change notification settings - Fork 207
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
Add nested MuSig #88
Comments
tomtau
pushed a commit
to crypto-com/secp256k1-zkp
that referenced
this issue
Jul 9, 2020
) Fix cargo warning output and wrong pointer width Co-Authored-By: tomaka <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Nested (or "composable") MuSig is the idea of signing for a combined key that itself consists of combined keys. Ideally, it would not be possible for a signer to determine whether a peer is a single or a combined key. But we don't know how to do that securely at the moment (see @ZmnSCPxj's post for an analysis of the challenges). What we can do instead is a "Multi-R" (non-transparent) variant, where every individual signer in the MuSig reveals their nonce commitment and nonce. However, in that case most protocols could just have the signers agree to flatten their MuSig tree to depth one by revealing their individual keys to each other without adding additional complexity or privacy issues.
The following is how I would imagine it to work in libsecp-zkp. Step 1 and 2 would probably be the same for multi-R and transparent nested MuSig.
secp256k1_musig_pubkey_combine
can be called multiple times with different pubkeys. For example, to get a combined key forA and (B and C)
, you'd first callpubkey_combine
with pubkeysB
andC
and then use the result to callpubkey_combine
withA
. If you're a signer, you should use a differentpre_session
for each level to allow signing with the correct musig coefficient later. Additionally we should make sure thatmusig_pubkey_tweak_add
also correctly works on the individual levels.secp256k1_musig_session_init
gets a new argument,n_layers
. Instead of providing a singlepre_session
, you provide an array ofn_layers
-manypre_sessions
. Instead ofsigners
being an array to signers, it's an array ofn_layers
-many pointers tosigners
arrays.n_signers
would be an array of sizen_layers
. Simlarly,my_index
will also an array ofn_layers
. We can also provide a new init function to not make the existing function more complicated than it is already.Every known signer presents a single nonce commitment as before. The difference is that a nonce commitment can either be opened with a nonce or with a list of more nonce commitments. For example, in a MuSig for
(A and (B and C))
,B
andC
exchange their nonce commitmentshash(R_B)
andhash(R_C)
. Then they combine their commitments intohash(hash(R_B), hash(R_C))
and send that to Alice. Later they reveal their tree of noncesR_B
andR_C
such that Alice can verify the commitment. The only changes for this code-wise is thatset_nonce
now gets a tree of nonce commitments and we need to decide how exactly to encode that. H/T to @roconnor for the tree commitment idea (also "If you do this, be sure to use tags so there is no ambiguity about whether you are hashing a nonce versus hashing a set of commitments.")The text was updated successfully, but these errors were encountered: