BIP-340 (Schnorr Signatures for Bitcoin)

What Is BIP-340?

BIP-340 is a Bitcoin Improvement Proposal authored by Pieter Wuille, Jonas Nick, and Tim Ruffing, published in January 2020. It specifies how Schnorr signatures operate on Bitcoin's secp256k1 elliptic curve, replacing the variable-length DER-encoded ECDSA signatures that Bitcoin used since its inception. The proposal forms the cryptographic foundation for the Taproot upgrade (BIP-341) and Tapscript (BIP-342).

Before BIP-340, Bitcoin relied exclusively on ECDSA for transaction signing. While ECDSA is secure, it lacks a property that cryptographers call linearity: the ability to combine multiple signatures into one. Schnorr signatures have this property, which unlocks a range of advanced constructions including multi-signature aggregation, threshold signatures, and adaptor signatures. These constructions improve privacy, reduce transaction sizes, and lower fees.

The scheme is designed with deliberate simplicity. It uses fixed-size 64-byte signatures, 32-byte x-only public keys, and a straightforward verification equation. This simplicity makes formal security proofs more tractable: BIP-340 Schnorr is provably secure under the random oracle model assuming the hardness of the elliptic curve discrete logarithm problem (ECDLP).

How It Works

BIP-340 defines three core operations: key generation, signing, and verification. Each incorporates specific design choices that optimize for Bitcoin's needs.

X-Only Public Keys

Every point on secp256k1 has two possible Y coordinates for a given X coordinate (one even, one odd). Traditional compressed public keys use a 33-byte encoding: one prefix byte (0x02 or 0x03) to indicate the Y parity, plus the 32-byte X coordinate.

BIP-340 eliminates the prefix byte by defining a convention: the public key always corresponds to the point with an even Y coordinate. If a private key produces an odd-Y public key, the signer negates the private key before signing. This saves 1 byte per public key and simplifies key aggregation schemes, since there is no parity ambiguity when summing keys.

The 32-byte x-only format is used in Taproot outputs (P2TR addresses), in witness data, and throughout Tapscript. It is fully compatible with existing key generation: any valid secp256k1 private key works with BIP-340.

Tagged Hashes

BIP-340 introduces tagged hashes to prevent cross-protocol hash collisions. A tagged hash is computed as:

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

The tag is a UTF-8 string that identifies the context. BIP-340 uses three tags: "BIP0340/aux" for auxiliary randomness, "BIP0340/nonce" for nonce derivation, and "BIP0340/challenge" for the signature challenge. Because the double-hashed tag produces a unique 64-byte prefix for each context, a hash output from one tag can never collide with a different tag's output, even if the input data is identical.

This domain separation is a security property: it prevents an attacker from taking a hash value computed in one protocol and reinterpreting it in another. The 64-byte tag prefix also aligns with SHA-256's block size, so implementations can precompute the initial hash state for each tag and reuse it across many operations.

Signing

To sign a message m with private key d:

1. Compute the public key P = d * G. If P has an odd Y coordinate, negate d so that P has an even Y
2. Generate auxiliary randomness a (32 random bytes) and compute a nonce seed using tagged_hash("BIP0340/aux", a) XORed with the private key
3. Derive nonce k from the seed, public key, and message using tagged_hash("BIP0340/nonce", ...)
4. Compute the nonce point R = k * G. If R has an odd Y, negate k
5. Compute the challenge: e = tagged_hash("BIP0340/challenge", bytes(R) || bytes(P) || m)
6. Output the signature as the 64-byte concatenation: bytes(R) || bytes((k + e * d) mod n)

Including the public key in the challenge hash (key prefixing) prevents related-key attacks where a signature valid for one key could be repurposed for a different key. The auxiliary randomness protects against side-channel attacks on the nonce generation without relying solely on deterministic derivation.

Verification

To verify a signature (r, s) against public key P and message m:

1. Lift P from its 32-byte x-only encoding to a full curve point (assuming even Y)
2. Compute the challenge: e = tagged_hash("BIP0340/challenge", r || bytes(P) || m)
3. Compute R' = s * G - e * P
4. Verify that R' is not the point at infinity, has an even Y coordinate, and that x(R ') equals r

If all checks pass, the signature is valid. This verification equation is a direct consequence of the signing formula: s = k + e * d, so s * G = k * G + e * d * G = R + e * P, which rearranges to R = s * G - e * P.

Batch Verification

When a node needs to verify many signatures at once (for example, all transactions in a new block), BIP-340 enables batch verification. Instead of checking each signature individually, the verifier combines them into a single multi-scalar multiplication:

(s1 + a2*s2 + ... + au*su) * G
  = R1 + a2*R2 + ... + au*Ru
  + e1*P1 + a2*e2*P2 + ... + au*eu*Pu

The coefficients a2...au are random values that prevent a cancellation attack where invalid signatures could mask each other. Batch verification is significantly faster than individual verification because it replaces multiple independent elliptic curve multiplications with a single combined operation. If any signature in the batch is invalid, the check fails with overwhelming probability.

The Linearity Property

The most consequential feature of Schnorr signatures is linearity: given signatures from multiple signers on the same message, they can be algebraically combined into a single valid signature for the sum of their public keys. In concrete terms, if Alice signs with key dA and Bob signs with key dB, their individual signatures can be aggregated into one signature that verifies against PA + PB.

This property directly enables several advanced protocols:

• MuSig2: an n-of-n key aggregation scheme where multiple parties produce a single 64-byte signature that is indistinguishable from a solo signature on-chain. See the MuSig2 deep dive for details.
• FROST: a flexible t-of-n threshold signature scheme built on Schnorr linearity. A subset of signers can produce a valid signature without revealing which members participated.
• Adaptor signatures: enable atomic swaps and PTLCs by linking signature validity to the revelation of a secret value.

ECDSA lacks this linearity, which is why pre-Taproot multisig required listing all public keys and signatures individually in the transaction, consuming more block space and revealing the spending policy to the network.

Relationship to Taproot and Tapscript

BIP-340 does not exist in isolation. It was designed as part of a three-BIP package that activated together as the Taproot soft fork:

• BIP-340: defines the Schnorr signature scheme
• BIP-341 (Taproot): defines a new output type (P2TR) that uses BIP-340 signatures for key-path spends and a Merkle tree of scripts for script-path spends
• BIP-342 (Tapscript): updates Bitcoin Script so that OP_CHECKSIG and OP_CHECKSIGADD validate BIP-340 Schnorr signatures instead of ECDSA. It removes ECDSA entirely from Tapscript execution

In the key-path spend case, a Taproot output looks like a single public key on-chain. Thanks to BIP-340's aggregation properties, this single key can actually represent an n-of-n multisig group, a threshold signing quorum, or complex spending conditions: all hidden behind one 32-byte key and one 64-byte signature. For a comprehensive overview, see the Taproot and Schnorr signatures explained research article.

Use Cases

Privacy-Preserving Multisig

Before Taproot, a 3-of-5 multisig transaction required encoding all five public keys and three signatures in the witness. Anyone inspecting the blockchain could see the multisig policy. With BIP-340 and MuSig2, the same 3-of-5 setup can produce a single key and signature via key-path spending, making it indistinguishable from an ordinary single-signer transaction.

Layer 2 Protocols

Layer 2 systems like Spark benefit from BIP-340's properties. FROST threshold signatures, built on Schnorr linearity, allow groups of operators to co-sign transactions without revealing the signing structure. Adaptor signatures enable trustless atomic operations between on-chain and off-chain state. These building blocks make off-chain protocols more compact and private.

Efficient Block Validation

Batch verification allows Bitcoin nodes to validate an entire block's worth of Schnorr signatures faster than checking each one individually. As Taproot adoption grows and more transactions use BIP-340 signatures, this performance gain becomes increasingly significant for node operators.

Cross-Input Signature Aggregation

Although not yet implemented in Bitcoin, BIP-340 lays the groundwork for cross-input signature aggregation: a future upgrade where all inputs in a transaction could share a single aggregate signature. This would dramatically reduce transaction sizes for UTXO consolidation, CoinJoin transactions, and other multi-input spending patterns.

Risks and Considerations

Nonce Generation

Schnorr signing is extremely sensitive to nonce quality. Reusing a nonce across two different messages leaks the private key entirely. BIP-340 mitigates this by combining deterministic nonce derivation (from the private key and message) with auxiliary randomness. The auxiliary randomness provides protection against differential fault attacks on hardware signing devices, while the deterministic component ensures nonces are never accidentally repeated even if the random number generator fails.

Multi-Party Signing Complexity

While BIP-340's linearity enables elegant multi-signature schemes, the protocols built on top (MuSig2, FROST) introduce their own complexity. Participants must coordinate nonce exchanges, handle abort cases, and avoid rogue-key attacks. These are solved problems at the protocol level, but incorrect implementations can compromise security.

Adoption and Compatibility

BIP-340 signatures are only valid within Taproot (P2TR) outputs. Legacy and SegWit v0 outputs continue to use ECDSA. Wallet software and signing devices must explicitly support Taproot key paths to benefit from Schnorr signatures. While adoption has grown since activation, many wallets and services still default to SegWit v0 addresses.

No Signature Malleability

BIP-340 Schnorr signatures are non-malleable: for a given key and message, exactly one valid signature exists. This is an improvement over ECDSA, where each signature has an inherent counterpart (due to the negation of the s value). Non-malleability simplifies transaction tracking and eliminates an entire class of potential attacks, but it also means that any system relying on ECDSA malleability behavior must be redesigned for Schnorr.

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.