In December 2010, at the 27th Chaos Communication Congress in Berlin, a hacker collective called fail0verflow walked on stage and showed the world Sony's most secret secret: the private key that signed every PlayStation 3 game. Sony's cryptography was correctly implemented. The curve was fine, the keys were fine, the signatures checked out. The company had made exactly one mistake, and it fit in a single number: they used the same random number to sign everything.
That number is called the nonce, and its catastrophic sensitivity is not a Sony bug or a 2010 bug — it is a property of how ECDSA signatures work, and it has emptied Bitcoin wallets too. This chapter shows you the algebra with numbers small enough to check by hand, and then the elegant fix that modern wallets quietly use: don't roll the nonce at all.
A Bitcoin signature is not made from the private key alone. Each signature also uses a fresh secret number, chosen at signing time, used once, and thrown away — the nonce ("number used once"). Call it \(k\). The signature is a pair of numbers computed from \(k\), the private key \(d\), and the message's hash \(z\), and the defining equation has this shape:
\[ s \;=\; \frac{z + r\,d}{k} \]— where \(r\) is a public part of the signature everyone sees. One honesty note: real signatures run this arithmetic on a clock-face of \(n\) values, where "division" means the modular cousin taught in the companion volume; this chapter uses ordinary division, and every step of the trick keeps its shape. The nonce \(k\) hides \(d\) inside that equation. That hiding is \(k\)'s only job — and it holds only while \(k\) is secret and used exactly once.
Two failure modes, then, both fatal. If \(k\) ever leaks, the equation solves for \(d\) in one step. And if \(k\) is ever reused on two different messages, the two public signatures — sitting on the blockchain for anyone to read — combine to expose both \(k\) and \(d\). No brute force, no search: school algebra.
Here is the whole catastrophe with toy numbers. Use ordinary division in place of the clock-arithmetic (the shape is identical; the companion volume does the real thing parameter by parameter). Let the secret key be \(d = 13\), the reused nonce be \(k = 7\), and the public \(r = 5\). Two signatures on two messages with hashes \(z_1 = 61\) and \(z_2 = 33\):
\[ s_1 = \frac{61 + 5 \times 13}{7} = \frac{126}{7} = 18 \qquad s_2 = \frac{33 + 5 \times 13}{7} = \frac{98}{7} = 14 \]The attacker sees \((r, s_1) = (5, 18)\) and \((r, s_2) = (5, 14)\) on-chain. The \(r\) values match — that is the alarm bell, since \(r\) comes from \(k\) alone. Now subtract the two equations: the \(r\,d\) terms cancel, and
\[ s_1 - s_2 = \frac{z_1 - z_2}{k} \quad\Longrightarrow\quad k = \frac{z_1 - z_2}{s_1 - s_2} = \frac{61 - 33}{18 - 14} = \frac{28}{4} = 7. \]The nonce is out. And with \(k\) known, either equation gives the key:
\[ d = \frac{s_1 \, k - z_1}{r} = \frac{18 \times 7 - 61}{5} = \frac{65}{5} = 13. \]Check that with nothing but a pencil: it is exact. The real attack is the same trick wearing modular arithmetic, run against the public ledger by anyone who can spot matching \(r\) values.
This is the sharpest edge in all of Bitcoin's cryptography. A private key can be generated perfectly — full 256 bits of fair entropy — and still fall to a signature-layer failure that has nothing to do with how well the key was chosen. The nonce is a second secret, made fresh per signature, and it tolerates zero mistakes.
Sony's mistake was exactly the toy one: the same nonce, every signature. Once fail0verflow collected two signed firmware files, the private signing key came out with the algebra of §10.2 — the master key to the console, recovered from public data, presented on stage.
Bitcoin's version arrived in August 2013, on Android. The platform's random number generator — the well from Chapter 6 — was faulty, and among its failures was this one: wallet apps signing transactions sometimes drew the same \(k\) twice. Matching \(r\) values began appearing on the public blockchain, and anyone scanning for them could run the algebra and sweep the coins. Bitcoin.org's alert pushed wallet updates; the coins already exposed were gone. Note the chain of causation: not a broken curve, not a broken hash — a dry well, turning into repeated nonces, turning into open keys.
Engineers being engineers, the response was not "be more careful." It was: remove the dice from the room. Modern wallets compute the nonce deterministically from the private key and the message — a construction standardized as RFC 6979: \(k\) is produced by keyed hashing of the message with the key, so the same message always yields the same \(k\) (harmless — identical inputs produce an identical signature, which leaks nothing new) and different messages always yield different, unpredictable \(k\)'s (because the key is in the mix). No fresh randomness is consumed at signing time at all.
Read what that accomplishes in this book's vocabulary: the entire entropy budget of custody moves to one moment — key generation. Chapter 6's well, drawn on once, properly, and then never needed again. The catastrophic per-signature dependency on live randomness is engineered out. This is why hardware wallets are safe to operate on compromised-by-entropy laptops: the nonce does not come from the laptop.
The case files are closed. Part IV's lesson, stated once: a Bitcoin key's security is entropy at generation, entropy never again — and history's thefts all bought their tickets at one of those two moments. Part V turns from autopsy to practice: how seed phrases carry 128 or 256 bits of fair entropy in a form a human can hold (Chapter 11 shows how those sit inside the 132 you counted), what alphabetizing the words costs (Chapter 1's counts, cashed in by Chapter 11), and the operational checklist that keeps all of this from being theoretical.
Exercise 10.1 ★ Pencil check. Using the chapter's toy values — \(d = 13\), \(k = 7\), \(r = 5\), \(z_1 = 61\), \(z_2 = 33\) — verify the two signatures \(s_1 = 18\) and \(s_2 = 14\), then carry out the attacker's two steps and recover \(k\) and \(d\) yourself.
Exercise 10.2 ★ The alarm bell. Two signatures on the blockchain show the same \(r\) value. What does a matching \(r\) tell the observer, and why? (Your answer needs one sentence and the fact that \(r\) comes from \(k\) alone.)
Exercise 10.3 ★★ A second toy. Let \(d = 9\), \(k = 5\), \(r = 3\), with message hashes \(z_1 = 23\) and \(z_2 = 8\). Compute \(s_1\) and \(s_2\), then recover \(k\) and \(d\) using §10.2's steps. You should get \(s_1 = 10\), \(s_2 = 7\), and back \(k = 5\), \(d = 9\).
Exercise 10.4 ★★ Why deterministic is safe here. With RFC 6979, signing the same message twice with the same key yields the same \(k\) — seemingly the reuse this chapter just condemned. Explain why it is not condemned: what would an attacker need two different of, for the algebra to work?
Exercise 10.5 ★★★ "The nonce catastrophe shows that Bitcoin signatures are fragile." Respond, using this chapter and Chapter 6: locate the fragility precisely (what is consumed, when, by whom), explain how RFC 6979 relocates it, and state what property of the generation moment everything then rests on.
Sketches, not model answers — enough to check your reasoning against. The computational exercises embed their expected outputs in the exercise text.
Exercise 10.2. A matching \(r\) means a matching \(k\): \(r\) comes from the nonce alone, so two signatures showing the same \(r\) were signed with the same nonce — the reuse this chapter prices is visible to anyone reading the chain.
Exercise 10.4. The reuse attack needs two different messages signed with the same nonce — that is what makes the subtraction eliminate the key term and solve for \(k\). Same message plus same nonce produces the same signature twice: two copies of one equation, and two copies of one equation are still one equation — nothing new to subtract, nothing new learned. RFC 6979 guarantees different messages get different nonces, so the dangerous pair can never be produced.
Exercise 10.5. The fragility is a consumption point: every signature used to drink fresh randomness, live, at signing time — a second secret with zero tolerance for error, drawn from whatever well the signing machine happened to have. Sony's well was a constant; Android 2013's was intermittently dry; both failures were fatal not because the key was weak but because the per-signature draw was. RFC 6979 removes the consumption point: the nonce is derived from the key and message by hashing, so signing needs no randomness at all. Everything then rests on the generation moment — 256 fair bits from Chapter 6's well, once — which is exactly the moment this whole book is about getting right, and exactly why Part V's practice is disciplined about it.