Schnorr Signatures

What Are Schnorr Signatures?

Schnorr signatures are a digital signature scheme invented by German mathematician Claus-Peter Schnorr in 1989. In the context of Bitcoin, they refer to the specific variant defined in BIP 340, which uses the secp256k1 elliptic curve already used by Bitcoin. The scheme produces signatures that are 64 bytes: smaller than the 71-72 byte DER-encoded ECDSA signatures Bitcoin originally used.

When Satoshi Nakamoto designed Bitcoin in 2008, Schnorr signatures were still covered by U.S. Patent 4,995,082. That patent did not expire until 2008, and no widely reviewed, standardized implementation existed at the time. ECDSA, which was patent-free and well-supported by the OpenSSL library Bitcoin depended on, was the pragmatic choice. Once the patent expired and years of cryptographic research matured the scheme, the Bitcoin community formally proposed Schnorr adoption through the Taproot upgrade.

For a comprehensive exploration of how Schnorr signatures interact with Taproot at the protocol level, see the research article on Taproot and Schnorr signatures explained.

How It Works

At its core, a Schnorr signature relies on the same elliptic curve discrete logarithm problem as ECDSA. A signer with private key x and corresponding public key P = xG (where G is the generator point) can prove knowledge of x without revealing it. The difference lies in how the proof is constructed.

Signing and Verification

The BIP 340 signing process works as follows:

1. The signer picks a random nonce k and computes the nonce point R = kG
2. The signer computes the challenge e = hash(R || P || m), where m is the message
3. The signer computes s = k + e * x
4. The signature is the pair (R, s), totaling 64 bytes

Verification checks that sG = R + eP:

# Schnorr signature verification (simplified)
# Given: public key P, message m, signature (R, s)

e = hash(R || P || m)

# Verify: s * G == R + e * P
# This works because:
#   s * G = (k + e * x) * G
#         = k * G + e * x * G
#         = R + e * P

The equation s = k + ex is linear in the private key. This linearity is what makes Schnorr fundamentally different from ECDSA, where the signing equation s = k⁻¹(z + rx) involves a modular inverse that breaks additivity.

Key Aggregation with MuSig

The linearity property means that if two parties hold private keys x₁ and x₂, they can compute an aggregate public key and produce a single signature that is valid under it. This is the foundation of the MuSig family of protocols.

The original MuSig protocol required three rounds of communication between signers. MuSig2, described in a 2020 paper by Nick, Ruffing, and Seurin, reduces this to two rounds, making it practical for interactive signing sessions. The process works as follows:

1. Each signer shares their public key. An aggregate key P_agg is computed deterministically from all participant keys using a hash-based coefficient scheme that prevents rogue key attacks
2. In round one, each signer generates nonces and shares the nonce points
3. In round two, each signer computes their partial signature using the aggregate nonce and challenge
4. The partial signatures are summed into a final signature (R_agg, s_agg) that validates against P_agg as a standard Schnorr signature

On-chain, this aggregate signature is indistinguishable from a single-signer Schnorr signature. A 3-of-3 MPC wallet and a solo user both produce identical 64-byte signatures. For deeper coverage of multisig architectures and how MuSig fits in, see the research article on Bitcoin multisig wallets explained.

Batch Verification

When a Bitcoin node validates a block, it must verify every signature in every transaction. With ECDSA, each signature requires a separate expensive elliptic curve operation. Schnorr signatures support batch verification: a technique where multiple signatures can be verified together faster than verifying each individually.

Batch verification works by combining multiple verification equations into a single multi-scalar multiplication. For n signatures, the node picks random weights a₁, a₂, ..., aₙ and checks:

# Batch verification of n Schnorr signatures
# Instead of verifying each s_i * G == R_i + e_i * P_i separately:

# Pick random weights a_1, a_2, ..., a_n
# Check: (a_1*s_1 + a_2*s_2 + ... + a_n*s_n) * G
#      == a_1*R_1 + a_1*e_1*P_1
#       + a_2*R_2 + a_2*e_2*P_2
#       + ...
#       + a_n*R_n + a_n*e_n*P_n

# This single multi-scalar multiplication is faster
# than n individual verifications

The random weights prevent a malicious signer from crafting invalid signatures that cancel each other out. In practice, batch verification can yield roughly 2x speedups for full block validation, reducing the time nodes spend on signature checks.

Adaptor Signatures

Adaptor signatures (also called signature adaptors) are a cryptographic construction built on top of Schnorr that enables atomic conditional payments. An adaptor signature is an "incomplete" signature that can only be finalized by someone who knows a specific secret value.

This is the mechanism behind point time-locked contracts (PTLCs), which are a proposed replacement for HTLCs in Lightning payment routing. Where HTLCs lock payments to a payment hash (revealing the same preimage at every hop), PTLCs lock payments to an elliptic curve point. Each hop uses a different adaptor point, so intermediate routing nodes cannot correlate hops of the same payment. This significantly improves routing privacy.

For more on how payment channels and routing work at the protocol level, see the research on payment channels from concept to implementation.

Use Cases

Taproot Key-Path Spends

The most common use of Schnorr signatures today is in Taproot key-path spends. When all parties to a UTXO agree on how to spend it, they can cooperatively sign with a single Schnorr signature regardless of the underlying spending policy. A 5-of-7 multisig, a time-locked escrow, or a complex script tree: all appear as a single public key and signature on-chain when resolved cooperatively.

Cooperative Lightning Channel Closes

When two parties close a Lightning channel cooperatively, they can use MuSig2 to produce a single Schnorr signature for the closing transaction. This makes the channel close indistinguishable from any other Taproot spend, improving privacy for Lightning users and reducing transaction weight compared to the two separate ECDSA signatures previously required.

Privacy-Preserving Multisig

Traditional Bitcoin multisig (using OP_CHECKMULTISIG) exposes the signing policy on-chain. Anyone analyzing the blockchain can see that a transaction required, for example, 2-of-3 signatures. With Schnorr key aggregation, the n-of-n cooperative case is completely hidden. Even for threshold schemes (like 2-of-3), the Taproot script tree only reveals the threshold path if the cooperative key-path fails.

Efficient Block Validation

Batch verification of Schnorr signatures allows full nodes to validate blocks faster. As Taproot adoption grows and more transactions use Schnorr, the cumulative benefit to network-wide validation performance increases. This is particularly relevant for resource-constrained nodes and initial block download (IBD) synchronization.

Risks and Considerations

Nonce Generation Is Critical

Schnorr signatures are acutely sensitive to nonce reuse. If a signer uses the same nonce k for two different messages, an attacker can trivially extract the private key from the two signatures. BIP 340 specifies a deterministic nonce generation scheme using the private key and message as inputs, but hardware wallets and multi-party signing protocols must be especially careful. In MuSig2, each signer generates multiple nonces per session to prevent certain classes of attack on the nonce aggregation process.

Interactive Signing for MuSig

MuSig and MuSig2 require all signers to be online and participate in the signing rounds. This interactivity is a constraint for scenarios like cold storage or air-gapped signing, where one key holder may be offline. For threshold setups where not all parties need to sign (e.g., 2-of-3), protocols like FROST (Flexible Round-Optimized Schnorr Threshold signatures) provide an alternative, though they introduce additional complexity.

Adoption and Ecosystem Maturity

While Schnorr signatures have been available since the Taproot activation in November 2021, adoption has been gradual. Wallet software, hardware signers, and infrastructure providers need to update their implementations to support Taproot and MuSig2. The cryptographic libraries underpinning MuSig2 (such as libsecp256k1-zkp) have undergone extensive review, but the ecosystem is still maturing. New applications building on Schnorr should use well-audited libraries and follow established implementation guidelines.

Quantum Computing Considerations

Like ECDSA, Schnorr signatures rely on the elliptic curve discrete logarithm problem, which is vulnerable to quantum computers running Shor's algorithm. Schnorr does not make Bitcoin more or less vulnerable to quantum attacks compared to ECDSA: both would need to be replaced by post-quantum signature schemes if large-scale quantum computers become practical.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.