dd83e72d52da0873e0c1a64c5554efa9000a3454 Add ordinary tweak info (Jesse Posner)
d26100cab266b08fd131503ba8e37d9bf091adbb Exclude nonce_process from pre-processing steps (Jesse Posner)
b7607f93f23a1a342b4fba552598e2a578f50527 Fix reference to xonly_tweak_add (Jesse Posner)

Pull request description:

ACKs for top commit:
  jonasnick:
    ACK dd83e72d52da0873e0c1a64c5554efa9000a3454

Tree-SHA512: b5b94e94625e235557d4a0d9973b14ef74be153b6bdd9a0701add9aa8af4a54411344030db2e65aaac701e3e6a0c1f46190f0d760f7314d426d077959271b615
This commit is contained in:
Jonas Nick 2022-09-02 12:20:07 +00:00
commit d22774e248
No known key found for this signature in database
GPG Key ID: 4861DBF262123605

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 # Key Aggregation and (Taproot) Tweaking
Given a set of public keys, the aggregate public key is computed with `secp256k1_musig_pubkey_agg`. 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 # 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`. 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. 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. 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. 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`. 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`. 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. 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. 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 # Verification