Merge elementsproject/secp256k1-zkp#203: MuSig doc fixes
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:
commit
d22774e248
@ -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
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user