What changed, and why it matters
This commit only fixes documentation comments in the code. It corrects a description about which nonce-generation method is used when a custom nonce option is provided. No actual signing logic or behavior was changed, so there is no security risk from this patch itself.
No security action needed; this is a documentation-only correction.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The change updates two comment blocks in btcec/schnorr/signature.go for schnorrSign and Sign. The previous comments incorrectly stated that CustomNonce triggers RFC6979 nonce generation; the corrected comments state that CustomNonce uses BIP-340 nonce derivation, while the default (no CustomNonce) uses RFC6979. It also fixes a typo ‘set 14’ to ‘step 14’. The diff contains no code changes.
Changed components
btcec/schnorr/signature.goInspect captured patch +10 / −6
diff --git a/btcec/schnorr/signature.go b/btcec/schnorr/signature.go
index 8876a60..37f9cc2 100644
--- a/btcec/schnorr/signature.go
+++ b/btcec/schnorr/signature.go
@@ -275,9 +275,11 @@ func schnorrSign(privKey, nonce *btcec.ModNScalar, pubKey *btcec.PublicKey, hash
// 15. return sig.
//
// Note that the set of functional options passed in may modify the
- // above algorithm. Namely if CustomNonce is used, then steps 6-8 are
- // replaced with a process that generates the nonce using rfc6979. If
- // FastSign is passed, then we skip set 14.
+ // above algorithm. If CustomNonce is used, steps 6-8 follow BIP-340's
+ // nonce derivation using the provided auxiliary randomness. If CustomNonce
+ // is NOT used (the default), steps 6-8 are replaced with RFC6979 nonce
+ // generation for deterministic signing. If FastSign is passed, we skip
+ // step 14 (signature verification).
// NOTE: Steps 1-9 are performed by the caller.
@@ -424,9 +426,11 @@ func Sign(privKey *btcec.PrivateKey, hash []byte,
// 15. return sig.
//
// Note that the set of functional options passed in may modify the
- // above algorithm. Namely if CustomNonce is used, then steps 6-8 are
- // replaced with a process that generates the nonce using rfc6979. If
- // FastSign is passed, then we skip set 14.
+ // above algorithm. If CustomNonce is used, steps 6-8 follow BIP-340's
+ // nonce derivation using the provided auxiliary randomness. If CustomNonce
+ // is NOT used (the default), steps 6-8 are replaced with RFC6979 nonce
+ // generation for deterministic signing. If FastSign is passed, we skip
+ // step 14 (signature verification).
// Step 1.
//
Why this scored 15/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.