MSTR Cat

Blockchain/Level II · Mechanics/2.1 Cryptography/Lesson 4

Digital signatures: ECDSA and Schnorr

The mathematical handshake that authorizes spending without exposing the key

MaterialsA block explorer that shows witness dataOne native SegWit spend and one Taproot key-path spend to compare

Wonder

  1. How does a signature prove control of a secret number without revealing it?
  2. Why did Sony’s PlayStation 3 and several Android bitcoin wallets lose their keys through reused or predictable nonces?
  3. What makes Schnorr signatures smaller, faster, and capable of aggregation compared to ECDSA?

Explore

  1. A digital signature proves ownership of a private key without disclosing it. In Bitcoin, spending a transaction output requires signing the transaction hash with the private key corresponding to the public key in that output’s locking script. The signature is verified by anyone using the public key and the message hash. This mechanism ensures only the key holder can authorize transfers while maintaining privacy.
  2. ECDSA, standardized in ANSI X9.62 (1999), has been Bitcoin’s primary signature scheme since 2009. It generates a pair of values (r, s) from the message hash and a secret nonce k. The r value is the x-coordinate of the point k·G; the s value is k⁻¹(hash + x·r) mod n, where x is the private key. Because each signature requires a fresh random k, reusing or leaking k allows an attacker to compute the private key directly.
  3. Sony’s PlayStation 3 signing key was compromised in 2010 when fail0verflow demonstrated that Sony reused the same nonce for all signatures. Bitcoin experienced similar thefts in August 2013 due to Android’s SecureRandom flaw, which produced predictable nonces. RFC 6979 (2013) resolved this by deriving k deterministically from the private key and message hash, eliminating reliance on external randomness sources.
  4. ECDSA signatures are malleable: for a given r, two valid s values exist (s and n−s). A third party could swap in the equivalent signature, changing the transaction’s ID without invalidating it. Bitcoin policy requires ‘low-S’ normalization, restricting s to the lower half of the curve order. This constraint ensures each message has only one canonical signature per nonce.
  5. Schnorr signatures, patented by Claus-Peter Schnorr (US patent granted 1991, expired 2008) and standardized for Bitcoin in BIP340, produce fixed-size 64-byte signatures without DER encoding overhead. They are linear: with a careful protocol, several public keys can be combined into one aggregate key and their signatures into one signature. This enables MuSig2 multisig schemes that appear as single-signer outputs on-chain, reducing transaction size and enhancing privacy.
  6. Taproot activated in November 2021 (block 709,632), introducing native Schnorr signature support for P2TR outputs. A key-path spend needs only a 64-byte signature in its witness, versus a 71-72-byte ECDSA signature plus a 33-byte public key for a P2WPKH spend. The fixed size simplifies parsing, and Schnorr permits batch verification, checking many signatures from different keys together faster than one by one, a capability Bitcoin Core does not yet use.

Key facts

  • ECDSA (ANSI X9.62, 1999) produces DER-encoded signatures of ~71–72 bytes; Schnorr (BIP340) produces fixed-size 64-byte signatures.
  • Reusing or leaking the ECDSA nonce k reveals the private key: Sony PS3 (2010) and Android wallet thefts (August 2013).
  • RFC 6979 derives k deterministically from the private key and message hash, eliminating reliance on random number generators.
  • ECDSA signatures are malleable; Bitcoin policy enforces ‘low-S’ to ensure canonical encoding.
  • Schnorr signatures are linear: keys and signatures can be aggregated (MuSig2) and batch-verified for efficiency.
  • Taproot activated in November 2021 (block 709,632), introducing native Schnorr signature support for P2TR outputs.

Exercise nine, six, three, one

9CollectList 9 digital signature schemes or key types. Note their standardization body, year, output size, and whether they support aggregation.
6ClusterGroup the 9 into 6 by verification complexity: fixed-size linear, variable-size malleable, variable-size canonical, batch-verifiable, single-party only, or hybrid.
3DistillReduce the 6 to 3 core trade-offs between signature size, privacy, and computational efficiency.
1CrystallizeWrite 1 sentence on what a digital signature guarantees about key control and what it does not reveal.

Fact check

Dates, figures and claims checked against the published sources listed below.

Open in the interactive academy →

PT ES ZH JA KO RU DE FR MS