frost/secp256k1-zkp
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge elementsproject/secp256k1-zkp#203: MuSig doc fixes

Browse Source 
dd83e72d52 Add ordinary tweak info (Jesse Posner)
d26100cab2 Exclude nonce_process from pre-processing steps (Jesse Posner)
b7607f93f2 Fix reference to xonly_tweak_add (Jesse Posner)

Pull request description:

ACKs for top commit:
  jonasnick:
    ACK dd83e72d52

Tree-SHA512: b5b94e94625e235557d4a0d9973b14ef74be153b6bdd9a0701add9aa8af4a54411344030db2e65aaac701e3e6a0c1f46190f0d760f7314d426d077959271b615
This commit is contained in:
Jonas Nick
2022-09-02 12:20:07 +00:00
parent f7e9a8544f dd83e72d52
commit d22774e248
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/modules/musig/musig.md
View File

@@ -23,7 +23,7 @@ Therefore, users of the musig module must take great care to make sure of the fo
# Key Aggregation and (Taproot) Tweaking
Given a set of public keys, the aggregate public key is computed with `secp256k1_musig_pubkey_agg`.
A (Taproot) tweak can be added to the resulting public key with `secp256k1_xonly_pubkey_tweak_add`.
A (Taproot) tweak can be added to the resulting public key with `secp256k1_xonly_pubkey_tweak_add` and an ordinary tweak can be added with `secp256k1_ec_pubkey_tweak_add`.
# Signing
@@ -32,7 +32,7 @@ Essentially, the protocol proceeds in the following steps:
1. Generate a keypair with `secp256k1_keypair_create` and obtain the xonly public key with `secp256k1_keypair_xonly_pub`.
2. Call `secp256k1_musig_pubkey_agg` with the xonly pubkeys of all participants.
3. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_tweak_add`.
3. Optionally add a (Taproot) tweak with `secp256k1_musig_pubkey_xonly_tweak_add` and an ordinary tweak with `secp256k1_musig_pubkey_ec_tweak_add`.
4. Generate a pair of secret and public nonce with `secp256k1_musig_nonce_gen` and send the public nonce to the other signers.
5. Someone (not necessarily the signer) aggregates the public nonce with `secp256k1_musig_nonce_agg` and sends it to the signers.
6. Process the aggregate nonce with `secp256k1_musig_nonce_process`.
@@ -42,10 +42,10 @@ Essentially, the protocol proceeds in the following steps:
The aggregate signature can be verified with `secp256k1_schnorrsig_verify`.
Note that steps 1 to 6 can happen before the message to be signed is known to the signers.
Note that steps 1 to 5 can happen before the message to be signed is known to the signers.
Therefore, the communication round to exchange nonces can be viewed as a pre-processing step that is run whenever convenient to the signers.
This disables some of the defense-in-depth measures that may protect against API misuse in some cases.
Similarly, 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 6).
Similarly, 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).
# Verification