MASTERING-BITCOIN

The Elegant Math Behind Bitcoin's Most Compact Signature

IKey Formulas

Formula	Name	Description
$s = k + e \cdot x$	Response equation	Combines nonce $k$ , challenge $e$ , and secret $x$
$sG \stackrel{?}{=} kG + e \cdot xG$	Verification check	Verifier confirms signature using only public values
$e = H(kG \,\Vert\, xG \,\Vert\, m)$	BIP340 challenge hash	Fiat-Shamir non-interactive challenge
$x = \dfrac{s_1 - s_2}{e_1 - e_2}$	Nonce-reuse recovery	If $k$ is reused, secret $x$ is exposed

IIVisualization 1: The Sigma Protocol Verification

The heart of Schnorr is the equation $sG = kG + e \cdot xG$ . To make this concrete, we'll work with scalar coefficients of $G$ — Alice's public key is $xG$ , her commitment is $kG$ , and the verifier checks that the scalar coefficients balance.

Adjust the secret $x$ , nonce $k$ , and challenge $e$ below to see how the response $s = k + e \cdot x$ is constructed and verified.

⚙ interactive visualization — coming to this page format soon

Notice: Both bars always have the same length, regardless of how you set $x$ , $k$ , or $e$ . This is the algebraic identity at the heart of Schnorr — multiplying $s = k + e \cdot x$ by $G$ gives exactly $kG + e \cdot xG$ . The verifier checks this equation using only public values ( $kG$ , $e$ , $xG$ ), never seeing the secret $x$ or the nonce $k$ .

IIIVisualization 2: The Nonce-Reuse Attack

The nonce $k$ is single-use. If Alice ever signs two different messages with the same $k$ , the secret $x$ is no longer secret — anyone can recover it with simple algebra.

Below, set Alice's secret $x$ , the reused nonce $k$ , and two different challenges $e_1, e_2$ . The plot shows how the attacker recovers $x$ from the two leaked signatures.

⚙ interactive visualization — coming to this page format soon

Reflect: Real Bitcoin wallets have been emptied this way — most famously, the Sony PlayStation 3 used a constant nonce in its ECDSA signing routine. BIP340 mandates deterministic nonce generation: $k = H(\text{private key} \,\Vert\, m)$ . This way the nonce is unpredictable to outsiders, but the same key + same message produces the same nonce — so two different messages produce two different nonces, and the attack is impossible.

IVVisualization 3: BIP340 Signature Layout

A BIP340 Schnorr signature is just two scalars worth of bytes. Compare its compactness to the older ECDSA format used in Bitcoin before Taproot.

⚙ interactive visualization — coming to this page format soon

Notice: BIP340 fixes the y-coordinate of $kG$ to be even, so only the x-coordinate needs to be transmitted. ECDSA must DER-encode two scalars of variable length (because leading zero bytes can shift), bloating the format. Multiply that ~7-byte savings by every input on every transaction in every block, and the scaling impact is real.

VQuiz Questions

Question 1

Alice's secret is $x = 4$ . She picks nonce $k = 9$ , and the challenge comes out to $e = 5$ . What is her response $s$ ?

✅ Correct! $s = 9 + 5 \cdot 4 = 29$ .

❌ Not quite. That's $k + e = 9 + 5$ . The formula is $s = k + e \cdot x$ — you need to multiply $e$ by $x$ first.

❌ Not quite. That's $(k+e) \cdot x = 14 \cdot 4$ (wrong order of operations). Compute $e \cdot x$ first, then add $k$ .

❌ Not quite. Apply $s = k + e \cdot x$ carefully.

Show solution

Solution:

The Schnorr response equation is: $s = k + e \cdot x$

Substituting: $s = 9 + 5 \cdot 4 = 9 + 20 = 29$

Verification check (in scalar coefficients of $G$ ): $sG = 29G \stackrel{?}{=} kG + e \cdot xG = 9G + 5 \cdot 4G = 9G + 20G = 29G$

The signature $(kG, s) = (9G, 29)$ verifies correctly.

Question 2

True or False: If Alice signs two different messages using the same nonce $k$ , the resulting signatures still keep her private key $x$ secret, because $x$ never appears in the signature directly.

✅ Correct! Reusing $k$ across two messages exposes $x$ via $x = (s_1 - s_2)/(e_1 - e_2)$ .

❌ Not quite. Although $x$ is masked by $k$ in a single signature, two signatures sharing the same $k$ let an attacker subtract them to cancel $k$ and solve for $x$ .

❌ Not quite. Try again — the hints above can help.

Show solution

Solution: False.

Reusing the nonce is catastrophic. Suppose Alice produces two signatures with the same $k$ :

$s_1 = k + e_1 \cdot x \qquad s_2 = k + e_2 \cdot x$

Subtracting eliminates $k$ entirely:

$s_1 - s_2 = (e_1 - e_2) \cdot x$

So anyone who sees both signatures can recover the secret directly:

$x = \frac{s_1 - s_2}{e_1 - e_2}$

This is exactly why BIP340 mandates deterministic nonce generation, $k = H(\text{private key} \,\Vert\, m)$ , which guarantees a fresh $k$ for every distinct message.

Question 3

BIP340 uses the challenge hash $e = H(kG \,\Vert\, xG \,\Vert\, m)$ , which includes the public key $xG$ as an input. What attack does including $xG$ in the hash specifically prevent?

✅ Correct! Including $xG$ in the hash makes the parent's challenge differ from any related child's, so the algebraic shift used in the forgery cannot succeed.

❌ Not quite. The specific role of $xG$ in the hash is to defeat forgeries that exploit related-key algebra (e.g., BIP32 child keys $xG + tG$ ).

Show solution

Solution: Key-shift forgeries.

Without $xG$ in the hash, the challenge is $e = H(kG \,\Vert\, m)$ — independent of which public key the verifier checks against. An attacker who knows a publicly derivable offset $t$ (as in BIP32 unhardened derivation, where the child key is $xG + tG$ ) can take Alice's signature $(kG, s)$ on the parent key and forge:

$s' = s + e \cdot t$

Then $s'G = sG + e \cdot tG = kG + e \cdot xG + e \cdot tG = kG + e \cdot (xG + tG)$ , which verifies under the child key for free.

Putting $xG$ inside the hash makes $e_{\text{parent}} \neq e_{\text{child}}$ , so the algebraic shift no longer lines up and the forgery dies.

The other options are unrelated:

Discrete log is prevented by the curve choice, not the hash inputs.
Message binding (preventing replay on different messages) comes from including $m$ in the hash.
Nonce brute-force is prevented by $k$ 's 256-bit entropy.

Question 4

In Schnorr's identity protocol, why must Alice send the commitment $kG$ before seeing Bob's challenge $e$ ?

✅ Correct! Without committing first, an attacker can pick $s$ freely and back-compute $kG = sG - e \cdot xG$ , producing a signature that verifies without knowing $x$ .

❌ Not quite. The ordering is load-bearing for security, not for performance or convenience. Think about what an attacker could do if they saw $e$ before committing to $kG$ .

Show solution

Solution: Reversing the order enables a trivial forgery.

If a (cheating) prover sees $e$ first, they can:

Pick any response $s$ they like (e.g., $s = 7$ ).
Take $e$ and the victim's public key $xG$ .
Compute $kG := sG - e \cdot xG$ .
Output the pair $(kG, s)$ .

Plug into the verifier: $sG \stackrel{?}{=} kG + e \cdot xG = (sG - e \cdot xG) + e \cdot xG = sG \quad \checkmark$

The signature verifies — yet the attacker never knew $x$ .

Committing to $kG$ first locks in a specific $k$ before $e$ is known, so $s = k + e \cdot x$ must be computed honestly using the secret $x$ . This commit-challenge-respond ordering is the heart of every sigma protocol, and it's exactly what the Fiat-Shamir transform must preserve (by hashing $kG$ together with $m$ to derive $e$ ).

Solved: 0 / 4