Bitcoin uses two distinct digital signature schemes, both built on the secp256k1 elliptic curve. ECDSA (Elliptic Curve Digital Signature Algorithm) is the original scheme — present since the genesis block and the only option for legacy address types (P2PKH, P2SH, P2WPKH, P2WSH). Schnorr signatures were added in the November 2021 Taproot upgrade (BIP-340/341/342) as a second scheme for Taproot outputs (P2TR), and the two coexist: a single transaction can spend ECDSA and Schnorr inputs simultaneously. ECDSA was the practical choice in 2008 (Schnorr was patent-encumbered until that year and not standardized for production use until much later). Schnorr has substantial advantages — shorter signatures, linear algebra enabling key and signature aggregation, native determinism, and no malleability — but legacy address types and ecosystem inertia ensure ECDSA will persist indefinitely. The note treats both schemes at the reference-conceptual level; deeper elliptic-curve mathematics lives in Public key cryptography.
Why this note matters
Signatures are the authorization layer of Bitcoin. Holding a private key means being able to produce signatures that the network will accept; without a valid signature for the relevant input, no transaction validates. Every Bitcoin spend, regardless of address type or wallet flavor, ultimately produces one or more signatures using one of these two schemes.
The Schnorr upgrade is the most consequential cryptographic change in Bitcoin’s history. It enables multisig configurations to look identical to single-sig on-chain (the same single Schnorr signature represents 2-of-3, 3-of-5, or arbitrary M-of-N multisig); it shrinks per-input signature size; it cleanly resolves the signature-malleability problems that plagued early ECDSA Bitcoin. Understanding both schemes is essential for engaging with contemporary Bitcoin’s privacy, efficiency, and composability characteristics.
What a digital signature is (recap)
A digital signature is a cryptographic proof produced with a private key over a message, verifiable by anyone with the corresponding public key. The required properties:
- Authenticity. The signature could only have been produced by the private key holder.
- Non-repudiation. The signer cannot later deny having signed.
- Integrity. Any modification to the message invalidates the signature.
- Verifiability. Anyone with the public key can verify the signature without trusting any third party.
In Bitcoin’s context, the “message” is a hash derived from the transaction the signer is authorizing (specifically, the signature-hash or sighash, which commits to the transaction’s inputs, outputs, and other relevant fields per the sighash flags used). The signer commits to the specific spend; the network verifies that commitment using only the public key on-chain.
For the underlying primitive (public key, private key, elliptic-curve math), see Public key cryptography.
ECDSA: the original scheme
ECDSA is a digital signature standard codified in ANSI X9.62 (1998) and updated through FIPS 186 (most recently 186-5, 2023). It is widely used outside Bitcoin — TLS, SSH, X.509 certificates, code signing — and well-understood cryptographically.
Structure of an ECDSA signature:
- Two integers
(r, s), each ~256 bits - DER-encoded: roughly 71-72 bytes in standard form, occasionally varying
- Plus a 1-byte sighash flag indicating which transaction fields were signed
- Total: ~72-73 bytes per signature in a Bitcoin transaction
Signing (conceptually):
- Compute the sighash from the transaction
- Choose a random nonce k (one-time, never repeated)
- Compute the signature
(r, s)using the private key, the nonce, and the sighash - Serialize and attach to the input
Verification:
- Reconstruct the sighash from the transaction
- Use the public key, sighash, and
(r, s)to verify - Reject if verification fails or if the signature is malformed
The nonce problem. ECDSA’s signing operation requires a fresh random nonce for every signature. Reusing a nonce across two different signatures leaks the private key. This is not a theoretical concern: the 2010 Sony PlayStation 3 ECDSA key leak was caused by Sony’s signing system using a constant nonce. In Bitcoin, an early Android wallet bug similarly leaked keys through poor nonce generation.
The standard mitigation, adopted widely in modern Bitcoin software, is deterministic signing per RFC 6979: the nonce is derived deterministically from the private key and the message via HMAC-SHA256. Same input always produces same nonce, but nonces vary across different messages. Reuse is impossible by construction.
ECDSA’s malleability problem. ECDSA signatures have a structural quirk: if (r, s) is a valid signature, then (r, -s mod n) is also a valid signature on the same message. An attacker who observes a transaction in the mempool can produce a different but equally valid signature, changing the transaction’s TXID without changing its semantics. This was exploited for griefing in early Bitcoin and was a load-bearing problem for early Lightning Network development.
The fix arrived in three stages:
- BIP-66 (2015): Strict DER encoding — rejected non-standard signature encodings.
- BIP-146 (2017, soft fork): Low-S enforcement — rejected signatures where s > n/2, eliminating the (r, s) vs (r, -s mod n) ambiguity.
- SegWit (2017): Moved signatures into the witness, where they don’t affect the TXID computation. This is the deeper structural fix.
Modern ECDSA Bitcoin transactions are not malleable in practice, but the legacy design quirk shaped the protocol’s evolution substantially.
Schnorr signatures: the Taproot upgrade
Schnorr signatures were proposed by Claus-Peter Schnorr in 1989 and patented; the patent expired in 2008 (the same year Bitcoin launched). Despite the timing, Schnorr signatures took 13 more years to be standardized for Bitcoin (BIP-340, November 2021) — partly because of the engineering investment required, partly because the ecosystem had built around ECDSA.
The Taproot upgrade activated November 14, 2021. It includes three BIPs:
- BIP-340 — Schnorr signature scheme over secp256k1
- BIP-341 — Taproot output type and spending mechanics
- BIP-342 — Tapscript, the script-execution rules for Taproot inputs
Structure of a Schnorr signature:
- Two 32-byte values
(R, s)concatenated - Total: 64 bytes per signature (versus 71-72 for ECDSA)
- The 8-byte savings per input compounds across multi-input transactions
Why Schnorr is structurally better:
- Shorter. 64 bytes versus 71-72 for ECDSA. Saves block space and lowers fees per input.
- Linear. Schnorr signatures are linear in the signing key, meaning multiple keys can be added together on the curve to produce a single aggregated key, and multiple signatures can be combined into a single aggregated signature.
- Native determinism. BIP-340 specifies deterministic signing by default; no RFC 6979 wrapper required.
- No malleability. Schnorr signatures don’t have the (r, s) vs (r, -s) duality. The scheme is cleanly non-malleable.
- Cleaner security proofs. ECDSA’s security depends on heuristic arguments; Schnorr has tight reductions to the ECDLP under standard assumptions.
The linearity property is the load-bearing advantage. Two specific consequences for Bitcoin:
- Key aggregation (MuSig2, FROST). A 3-of-3 multisig can be expressed as a single aggregated public key. On-chain, the output looks identical to a single-sig P2TR. Spenders produce a single 64-byte aggregated signature. This is massive for privacy — multisig users no longer leak their multisig structure to chain analysis — and for efficiency — multisig outputs no longer cost more bytes than single-sig.
- Threshold signatures. M-of-N threshold schemes can produce a single aggregated signature representing M cooperating signers. FROST is the primary M-of-N protocol; deployment is still maturing in 2026.
The script-path alternative. Taproot outputs (P2TR) can be spent two ways: via the key path (a Schnorr signature on the output’s public key) or via the script path (revealing an alternative script committed to via Merkle trees — the TapTree). The vast majority of Taproot spends use the key path, which is what gives Taproot its privacy and efficiency story.
Where each scheme is used
ECDSA outputs:
- P2PKH (Pay-to-Public-Key-Hash) — legacy
1...addresses. ECDSA signature in the scriptSig (pre-SegWit). - P2SH (Pay-to-Script-Hash) — legacy
3...addresses. ECDSA signature(s) in the scriptSig. - P2WPKH (native SegWit v0,
bc1q...short) — ECDSA signature in the witness. - P2WSH (native SegWit v0,
bc1q...long) — ECDSA signature(s) in the witness.
Schnorr outputs:
- P2TR (Pay-to-Taproot, SegWit v1,
bc1p...) — Schnorr signature in the witness, either for key path or for script path (in tapscript, both ECDSA and Schnorr opcodes are available, but Schnorr is dominant).
Coexistence. A single Bitcoin transaction can spend ECDSA inputs and Schnorr inputs simultaneously. Each input is signed using whichever scheme the output type requires.
Adoption trajectory. Taproot adoption has been gradual since November 2021: by mid-2024 roughly 15-20% of transactions used Taproot inputs; by 2026 the share is higher but ECDSA still dominates by output count due to massive legacy UTXO sets. Migration is voluntary and gradual.
For the operational implications of address-type choice on Self-custody, see Bitcoin addresses.
Properties the primitive provides
Both schemes provide:
- Authenticity, non-repudiation, integrity, verifiability (standard digital-signature properties)
- ~128-bit security against classical attacks (assuming the ECDLP is hard for secp256k1)
Schnorr-specific properties:
- Linearity → key and signature aggregation
- Native non-malleability
- Native determinism (no RFC 6979 wrapper required)
- 8 bytes shorter per signature
Neither scheme provides:
- Quantum resistance. Both depend on ECDLP hardness; both are broken by Shor’s algorithm on a sufficiently capable quantum computer. The threat is engaged in Quantum computing threat to Bitcoin; migration options in The post-quantum migration debate.
- Privacy of the signed message. Signatures prove authorization; they do not hide what was authorized. The transaction itself remains public on the chain.
- Identity binding. Public keys do not identify legal entities or jurisdictions. Identity binding (if needed) comes from external context.
Tradeoffs and design choices
Why ECDSA in 2008? Satoshi chose ECDSA over Schnorr in 2008 for the same reasons most cryptographic engineers did at the time: ECDSA was standardized (X9.62, FIPS 186), patent-free, well-understood, and present in widely-deployed libraries. Schnorr signatures, despite cryptographic advantages, had been patent-encumbered until 2008 and had not yet acquired ecosystem support. The choice was prudent given the constraints.
Why both schemes coexist, rather than migrating fully to Schnorr? A clean migration would require either invalidating legacy UTXOs (catastrophic for users with old funds) or a complex re-signing protocol. The chosen approach was dual standards: new outputs can use Schnorr; legacy outputs keep working with ECDSA. The migration happens organically as users spend old UTXOs and create new Taproot ones.
The size tradeoff. Schnorr signatures save 8 bytes per signature; for a multi-input transaction, this compounds. The per-block size savings (multiplied by Bitcoin’s fee market) makes Schnorr operationally cheaper to use — providing a market-based incentive for migration that doesn’t require coercion.
MuSig2 versus FROST. Multiple multisig protocols built on Schnorr’s linearity have emerged. MuSig2 (Nick et al., 2020) is the simpler n-of-n protocol; FROST (Komlo and Goldberg, 2020) handles m-of-n thresholds. Both are still seeing deployment refinement in 2026 — the protocols are mature on paper but operational deployment in wallets and signing infrastructure has been slower than the underlying cryptography would suggest.
The Tapscript alternative. Within Taproot’s script path, BIP-342 introduces Tapscript — a variant of Bitcoin Script with both ECDSA and Schnorr signature-checking opcodes. Most production deployments use Schnorr in script-path spends, but the dual support exists for transition flexibility. See Bitcoin Script and opcodes.
Adaptor signatures and discrete-log-equivalence proofs. Schnorr’s algebraic structure also enables more sophisticated cryptographic constructions: adaptor signatures (used in some Lightning Network proposals), discreet log contracts (DLC), and atomic swaps. ECDSA can be adapted for some of these but with substantially more complexity.
For substantive engagement with the quantum threat to both schemes, see Quantum computing threat to Bitcoin (Criticisms section, analytical engagement) and The post-quantum migration debate (Controversies section, the question of which post-quantum scheme Bitcoin should adopt and when).
Open questions for further development
- Will the M-of-N Schnorr multisig protocols (FROST, MuSig2 variants) reach production deployment in mainstream wallets in the near term? The cryptography is settled; the operational deployment has been slow.
- Is there a structural advantage to migrating to a single signature scheme eventually, or is the dual standard (ECDSA + Schnorr) workable indefinitely? The pragmatic answer in 2026 is dual indefinitely.
- For post-quantum migration: do new outputs migrate to a post-quantum signature scheme alongside Schnorr’s replacement, or in sequence? The post-quantum signature schemes being considered (FALCON, SPHINCS+, lattice-based alternatives) have substantially larger signatures than either ECDSA or Schnorr, which interacts with block-size limits.
- How should wallet UX present the Schnorr-versus-ECDSA distinction (if at all) to non-technical holders? The dominant view is that the distinction should be invisible — wallets choose based on output type — but holders configuring inheritance or multisig sometimes need to understand the operational implications.
Canonical sources for this note
Standards documents
- FIPS 186-5 — NIST’s Digital Signature Standard covering ECDSA. Free at nist.gov.
- ANSI X9.62 — the original ECDSA specification.
- RFC 6979 — deterministic ECDSA signing.
- BIP-340 — Schnorr signatures for Bitcoin.
- BIP-341 — Taproot output type and spending mechanics.
- BIP-342 — Tapscript validation rules.
- BIP-66 — Strict DER encoding (ECDSA malleability fix part 1).
- BIP-146 — Low-S enforcement (ECDSA malleability fix part 2).
Bitcoin engineering references
- Mastering Bitcoin, Andreas Antonopoulos (chapter 4: “Keys, Addresses”; chapter 6: “Transactions”) — the canonical engineering treatment. See Mastering Bitcoin - Andreas Antonopoulos.
- Programming Bitcoin, Jimmy Song (chapter 3: “Elliptic Curve Cryptography”; chapter 7: “Transaction Creation and Validation”) — working-programmer treatment of ECDSA implementation specifically.
Schnorr-specific research
- Simple Schnorr Multi-Signatures with Applications to Bitcoin — Maxwell, Poelstra, Seurin, Wuille (2018; the MuSig original paper).
- MuSig-DN: Schnorr Multi-Signatures with Verifiably Deterministic Nonces — Nick, Ruffing, Seurin, Wuille (2020).
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures — Komlo and Goldberg (2020).
Cryptographic foundations (for the textbook depth this note defers)
- Handbook of Applied Cryptography, Menezes et al. (chapter 11: “Digital Signatures”) — the standard reference.
Quantum-threat research
- Bitcoin & Quantum Computing, NVK research series at bitcoinquantum.space — load-bearing for the post-quantum signature considerations. See Rodolfo Novak.
Related notes
- Public key cryptography — The underlying primitive both schemes build on; secp256k1 specifically.
- SHA-256 — Used in computing sighashes (the message a signature commits to) and in tagged-hash constructions inside BIP-340.
- Merkle trees — The TapTree (Taproot’s script-path commitment) uses Merkle-tree structure.
- Bitcoin addresses — Address types determine which signature scheme is used; legacy/SegWit-v0 use ECDSA, P2TR uses Schnorr.
- UTXO model and Bitcoin transactions — Signatures attach to transaction inputs; the sighash is computed over the transaction structure.
- Bitcoin Script and opcodes — Tapscript defines signature-checking opcodes for both ECDSA and Schnorr in the script path.
- Multisig setups — Operational treatment of multisig in Self-custody; Schnorr’s key aggregation transforms multisig privacy and efficiency.
- Quantum computing threat to Bitcoin — Substantive engagement on the quantum threat to both signature schemes. Criticisms section.
- The post-quantum migration debate — Event-level engagement on which post-quantum scheme Bitcoin should migrate to. Controversies section.
- Pieter Wuille — Co-author of BIP-340 Schnorr and BIP-341 Taproot; the load-bearing protocol contributor for Schnorr’s Bitcoin deployment.
- Greg Maxwell — Co-author of MuSig2 and related cryptographic protocols.