Inside Bitcoin
Opening the selected file…
Inside Bitcoin
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
1Notes on the musig module API2===========================4The following sections contain additional notes on the API of the musig module (`include/secp256k1_musig.h`).5A usage example can be found in `examples/musig.c`.7## API misuse9The musig API is designed with a focus on misuse resistance.10However, due to the interactive nature of the MuSig protocol, there are additional failure modes that are not present in regular (single-party) Schnorr signature creation.11While the results can be catastrophic (e.g. leaking of the secret key), it is unfortunately not possible for the musig implementation to prevent all such failure modes.13Therefore, users of the musig module must take great care to make sure of the following:151. A unique nonce per signing session is generated in `secp256k1_musig_nonce_gen`.16See the corresponding comment in `include/secp256k1_musig.h` for how to ensure that.172. The `secp256k1_musig_secnonce` structure is never copied or serialized.18See also the comment on `secp256k1_musig_secnonce` in `include/secp256k1_musig.h`.193. Opaque data structures are never written to or read from directly.20Instead, only the provided accessor functions are used.22## Key Aggregation and (Taproot) Tweaking24Given a set of public keys, the aggregate public key is computed with `secp256k1_musig_pubkey_agg`.25A plain tweak can be added to the resulting public key with `secp256k1_ec_pubkey_tweak_add` by setting the `tweak32` argument to the hash defined in BIP 32. Similarly, a Taproot tweak can be added with `secp256k1_xonly_pubkey_tweak_add` by setting the `tweak32` argument to the TapTweak hash defined in BIP 341.26Both types of tweaking can be combined and invoked multiple times if the specific application requires it.28## Signing30This is covered by `examples/musig.c`.31Essentially, the protocol proceeds in the following steps:331. Generate a keypair with `secp256k1_keypair_create` and obtain the public key with `secp256k1_keypair_pub`.342. Call `secp256k1_musig_pubkey_agg` with the pubkeys of all participants.353. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_xonly_tweak_add` and a plain tweak with `secp256k1_musig_pubkey_ec_tweak_add`.364. Generate a pair of secret and public nonce with `secp256k1_musig_nonce_gen` and send the public nonce to the other signers.375. Someone (not necessarily the signer) aggregates the public nonces with `secp256k1_musig_nonce_agg` and sends it to the signers.386. Process the aggregate nonce with `secp256k1_musig_nonce_process`.397. Create a partial signature with `secp256k1_musig_partial_sign`.408. Verify the partial signatures (optional in some scenarios) with `secp256k1_musig_partial_sig_verify`.419. Someone (not necessarily the signer) obtains all partial signatures and aggregates them into the final Schnorr signature using `secp256k1_musig_partial_sig_agg`.43The aggregate signature can be verified with `secp256k1_schnorrsig_verify`.45Steps 1 through 5 above can occur before or after the signers are aware of the message to be signed.46Whenever possible, it is recommended to generate the nonces only after the message is known.47This provides enhanced defense-in-depth measures, protecting against potential API misuse in certain scenarios.48However, it does require two rounds of communication during the signing process.49The alternative, generating the nonces in a pre-processing step before the message is known, eliminates these additional protective measures but allows for non-interactive signing.50Similarly, the API supports an alternative protocol flow where generating the aggregate key (steps 1 to 3) is allowed to happen after exchanging nonces (steps 4 to 5).52## Verification54A participant who wants to verify the partial signatures, but does not sign itself may do so using the above instructions except that the verifier skips steps 1, 4 and 7.
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.