Step 1 of 5 · Reading · ~1 min

Schnorr Signatures (BIP-340)

Implementation Pitfalls

Schnorr vs ECDSA

ECDSA was patented (until 2008) so the world standardized on it. Schnorr — invented earlier, simpler, with better properties — was the obvious right answer all along.

Bitcoin activated BIP-340 Schnorr at the Taproot soft-fork (Nov 2021).

The signature

Same curve (secp256k1), same generator G, same n. Public key is now x-only (32 bytes — Schnorr fixes the y-coordinate to be even). Signature is 64 bytes: R.x || s.

Sign:

k = (tagged-hash random)        (deterministic — derived from d, P.x, msg, aux)
R = k * G                       (if R.y is odd, negate k)
e = H_challenge(R.x || P.x || msg)   mod n
s = (k + e * d)                 mod n
sig = R.x || s

Verify:

e = H_challenge(R.x || P.x || msg)   mod n
R' = s*G - e*P
accept iff R'.y is even AND R'.x == R.x

Why this is better

Property	ECDSA	Schnorr
Linearity	nope (s involves k^{-1})	yes — sigs are linear in d and k
Batch verify	one at a time	dozens at once (~2-3x speedup)
Provable security	only in GGM	provable in ROM under DLP
Key/sig aggregation	hacks like MuSig-DN	natural with MuSig2
Malleability	yes (high-s flip)	no

Tagged hashes

BIP-340 prefixes SHA-256 with a domain tag to prevent cross-protocol replay:

tagged_hash(tag, m) = SHA256( SHA256(tag) || SHA256(tag) || m )

The tags used are "BIP0340/aux", "BIP0340/nonce", "BIP0340/challenge".

When to pick Schnorr

Bitcoin Taproot, Lightning Network, MuSig2 multisig.
Anywhere you batch-verify many signatures (block validation, blockchain sync).
Threshold signing without trusted setup (FROST).

Next: Verify Schnorr Signature (BIP-340)

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Loading…