@@ -75,14 +75,24 @@ SECP256K1_API int secp256k1_schnorrsig_parse(
75
75
* 2. The client commits to its sign-to-contract original nonce (which is the nonce without the
76
76
* sign-to-contract tweak) using the hosts commitment by calling the
77
77
* `secp256k1_schnorrsig_anti_nonce_sidechan_client_commit` function. The client sends the
78
- * rusulting commitment to the host
78
+ * resulting commitment to the host
79
79
* 3. The host replies with the randomness generated in step 1.
80
80
* 4. The client signs with `schnorrsig_sign` using the host provided randomness as `s2c_data` and
81
81
* sends the signature and opening to the host.
82
82
* 5. The host checks that the signature contains an sign-to-contract commitment to the randomness
83
83
* by calling `secp256k1_schnorrsig_anti_nonce_sidechan_host_verify` with the client's
84
84
* commitment from step 2 and the signature and opening received in step 4. If verification does
85
85
* not succeed, the protocol failed and can be restarted.
86
+ *
87
+ * Rationale:
88
+ * - The reason for having a host commitment is to allow the client to derive a unique nonce
89
+ * for every host randomness. Otherwise the client would reuse the original nonce and thereby
90
+ * leaking the secret key to the host.
91
+ * - The client does not need to check that the host commitment matches the host's randomness.
92
+ * That's because the client derives its nonce using the hosts randomness commitment. If the
93
+ * commitment doesn't match then the client will derive a different original nonce and the
94
+ * only result will be that the host is not able to verify the sign-to-contract commitment.
95
+ * Therefore, the client does not need to maintain state about the progress of the protocol.
86
96
*/
87
97
88
98
/** Create a randomness commitment on the host as part of the Anti Nonce Sidechannel Protocol.
0 commit comments