LearnBitcoin

Glossary

ECDSA (Elliptic Curve Digital Signature Algorithm)

Bitcoin's original signature scheme for proving ownership, still used by every pre-Taproot output type alongside Taproot's Schnorr signatures.

ECDSA is Bitcoin's original digital signature scheme. It's how the network has verified, since 2009, that the person spending a UTXO is the one who actually controls the private key it was sent to.

The mechanism is built on the secp256k1 elliptic curve. Roughly:

  1. A signer with private key d produces a signature (r, s) that depends on d, the message being signed, and a secret nonce k (random in textbook ECDSA; libsecp256k1 derives it deterministically from the key and message per RFC 6979).
  2. Anyone with the corresponding public key can verify the signature is mathematically consistent - meaning whoever signed must have known d.
  3. The verifier learns nothing about d in the process.

Production ECDSA implementations also have to follow strict constant-time discipline: the scalar multiplication step in signing leaks key bits through timing if implemented naively, and a 2011 attack recovered a TLS server's ECDSA key from a scalar-multiplication timing leak in OpenSSL. Bitcoin Core's libsecp256k1, built to be free of timing side channels for secret-key operations, is one of the more carefully-engineered constant-time signers in production cryptography.

ECDSA works, but it has some annoyances:

  • Signature malleability. A given signature (r, s) can be trivially massaged into (r, n - s), where n is the curve order. Both verify against the same key for the same message. This caused real headaches for transaction-ID stability. SegWit fixed it for the inputs that use it, by taking signatures out of the data the transaction ID is computed from.
  • No native aggregation. Five cosigners on a multisig output produce five separate signatures, each occupying space on-chain. There's no clean way to compress them.
  • Slightly awkward proofs. Provable security results for ECDSA are messier than for Schnorr.

Schnorr signatures, activated with Taproot in November 2021 at block 709,632, address all three issues. ECDSA is still used by every pre-Taproot output type (P2PK, P2PKH, P2SH, P2WPKH, P2WSH) and remains the most-tested signature scheme in production Bitcoin. Taproot outputs use Schnorr only: the key path verifies a BIP 340 signature, and tapscript's OP_CHECKSIG was redefined for Schnorr keys and signatures instead of ECDSA.

ECDSA's security rests on the elliptic-curve discrete logarithm problem being computationally hard. That assumption is broken by Shor's algorithm on a sufficiently powerful quantum computer. See Post-Quantum Bitcoin for the migration framework.

Key takeaways

  • Elliptic curve-based method for signing transactions
  • Formed the cornerstone of Bitcoin's cryptographic security
  • Schnorr signatures now coexist, bringing potential benefits

On the mailing list

The topic timeline: Signatures and cryptography (155 threads).

Corrected

  • Was: The entry called P2WPKH and P2WSH legacy address types and said new Taproot outputs use Schnorr 'by default'.

    Now: P2WPKH and P2WSH are SegWit v0 output types, not legacy ones; what they share with P2PKH and P2SH is that they are pre-Taproot and still use ECDSA. Taproot outputs use Schnorr only: BIP 341 key path spends verify a BIP 340 signature and BIP 342 redefines OP_CHECKSIG for Schnorr instead of ECDSA, with no ECDSA option. Details

Sources (7)

External references (3)

Related terms (11)

Published . Revised . One correction logged for this page.

Edit this page on GitHub