Deterministic Nonce (RFC 6979)

A deterministic nonce, specified in RFC 6979, is a way of generating the secret per-signature value k used in ECDSA without relying on a random number generator. Instead, k is computed as a pseudorandom function of the message hash and the private key, so the same key signing the same message always yields the same nonce — and, crucially, different messages always yield different nonces. One clarification for miners before going further: this signing nonce has nothing to do with the nonce ground during proof-of-work; the two merely share a name.

Why the signature nonce is so dangerous

ECDSA fails catastrophically if k is ever reused across two different signatures. An attacker who observes two signatures sharing a nonce can subtract one signing equation from the other, eliminating the unknown k, and solve directly for the private key. Not weaken it — recover it outright, with grade-school algebra, from data published on a public blockchain. Even without exact reuse, any bias or partial predictability in k is exploitable through lattice attacks that accumulate leaked bits across many signatures. History supplies the object lessons: Sony's PlayStation 3 firmware-signing key was recovered because their implementation used a constant k, and the 2013 Android SecureRandom flaw produced repeated nonces in mobile Bitcoin wallets — funds were swept by automated scanners the moment vulnerable signatures appeared on-chain. To this day, bots continuously scan the blockchain for nonce reuse and drain anything they find within seconds. The failure mode is catalogued in our nonce reuse entry, and it remains the sharpest edge in all of elliptic-curve cryptography.

How RFC 6979 removes the risk

The insight behind RFC 6979 is that the nonce never needed to be random — it needed to be unpredictable to attackers and unique per message. Deriving k deterministically via HMAC-DRBG, keyed on the private key and the message hash, delivers both properties without touching a random source at all. A different message changes the hash, which changes the derived nonce; the private key's secrecy makes the output unpredictable to anyone else; and a device with a broken, biased, or backdoored RNG can still sign safely because signing no longer consumes randomness. Determinism also buys testability — implementations can be verified against fixed test vectors, something impossible with random nonces. This is now standard practice across Bitcoin Core and essentially every serious wallet library operating on secp256k1.

The Schnorr refinement

The Schnorr signature scheme standardized in BIP340 for Taproot uses a related but deliberately hybrid construction: the nonce is derived deterministically, but with auxiliary randomness mixed in when available. Pure determinism has its own subtle hazard — if a signer can be induced to sign the same message twice while an attacker glitches or fault-injects the computation, identical nonces with differing outputs can leak the key — so mixing in randomness hedges against fault attacks while the deterministic base still protects against bad RNGs. Belt and suspenders, chosen deliberately.

One operational corollary is worth spelling out: because RFC 6979 removes randomness from signing, two wallets implementing it will produce byte-identical signatures for the same key and message — a property auditors actively use to cross-check implementations against each other and against published test vectors. If you are evaluating wallet software, RFC 6979 (or BIP340's construction) appearing in the signing path is a baseline competence signal, and its absence is a question that deserves an answer.

For self-custody the takeaway is quiet but foundational: every signature your hardware wallet produces exposes the private key behind it if the nonce discipline slips even once, and RFC 6979 is the reason that discipline no longer depends on the quality of a random-number chip. It is a fine example of Bitcoin-adjacent engineering culture: eliminate the dependency rather than trust it.