BIP-340 (Schnorr Signatures for secp256k1)

BIP-340 is the document that defines how a Schnorr signature is made and checked on Bitcoin's curve. Claus Schnorr published the underlying scheme in 1989, but there was no standard for using it with secp256k1, and a signature scheme without an exact specification is a consensus bug waiting to happen. The BIP's authors, Pieter Wuille, Jonas Nick, and Tim Ruffing, set out to fix that. The first draft went to the bitcoin-dev list in July 2018, the number was assigned in January 2020, and the scheme went live on mainnet with Taproot in November 2021.

The specification makes four choices worth knowing. Public keys are x-only, 32 bytes instead of 33, with the Y coordinate implied to be even. Signatures are a fixed 64 bytes, the X coordinate of a nonce point R followed by a scalar s, instead of ECDSA's variable-length DER encoding of up to 72 bytes. Every hash inside the scheme is a tagged hash, so a hash computed for one purpose can never be mistaken for one computed for another. And the challenge value commits to the public key as well as the nonce and message, which blocks a class of related-key attacks that would otherwise break BIP32 derivation and the Taproot tweak.

The verification equation is s*G = R + e*P, with e = hash(r || P || m). Because that equation is linear, signatures from several keys on the same message add up to a valid signature for the sum of the keys, which is the basis for MuSig2 and for every design that makes a multi-party spend look like a single one. Linearity also lets a verifier check many signatures in one combined equation; the BIP was written so that batch verification is possible, though as of 2026 Bitcoin Core still checks signatures one at a time.

The BIP also pins down signing. Reusing a nonce leaks the private key, so the default signer derives its nonce from the secret key, the message, and 32 bytes of fresh randomness together, and verifies its own output before releasing it. That is safe even with a poor random number generator. Multi-party signing is the exception: MuSig2 nonces must never be deterministic, and the BIP says so.

BIP-340 applies only to SegWit version 1, meaning Taproot key-path spends and Tapscript signature checks. Every legacy and SegWit version 0 spend still uses ECDSA, and most bitcoin still sits in those outputs. The scheme is not quantum resistant either; it rests on the same discrete logarithm problem as ECDSA. Outside Bitcoin, the same specification is used by Nostr and by Lightning's BOLT 12 offers.

See How Taproot Actually Works for what the scheme changed in practice, and for the patent story that most explainers get wrong.