Schnorr signature

ECDSA signatures run 71 or 72 bytes and cannot be combined; Schnorr signatures are always 64 and can. That difference is why two signers, or fifteen, can produce a single signature verifying against a single public key, with nothing on-chain to say how many of them there were. Bitcoin got the scheme in BIP-340, created in January 2020 and enforceable from block 709,632.

How it works

The scheme uses the same elliptic curve bitcoin has always used, secp256k1, and the same private keys. What changes is the algebra around them.

To sign, you pick a secret nonce, publish the point it generates as R, and compute a single number s from the nonce, a hash of R together with the public key and the message, and your private key. The signature is R and s written out as 32 bytes each, which is where the fixed 64 byte length comes from. Verification rearranges the same equation and checks that two points match. ECDSA needs a modular inversion in the middle of this; Schnorr does not, and that missing inversion is the reason the whole thing stays linear.

Linearity is the practical payoff. Add two private keys and the sum signs for the sum of the two public keys, so a group can hold one apparent key between them. It also permits batch verification: a node validating a block can check hundreds of signatures in one aggregated operation rather than one at a time, which matters most during initial block download.

Two details in BIP-340 exist to prevent footguns. Public keys are x-only, 32 bytes with the y coordinate implied, which removes the ambiguity that two encodings of the same key used to create. And every hash is a tagged hash, prefixed with a domain string, so a signature made for one purpose can never be replayed as valid in another protocol that happens to hash similar bytes.

The nonce remains the sharp edge. Reusing one across two different messages exposes the private key through simple arithmetic, exactly as it does with ECDSA, which is why BIP-340 specifies a deterministic derivation mixed with optional auxiliary randomness rather than leaving the choice to implementers.

There is a reason none of this arrived in 2009. Claus Schnorr held US patent 4,995,082 over the scheme, and it did not expire until February 2008, a few months before the bitcoin whitepaper appeared. ECDSA was the unencumbered standard at the time, so bitcoin shipped with the second best option and waited twelve years to correct it.

Why this matters when you buy bitcoin

For a single key wallet the effect is a rounding error, and for anyone protecting a serious amount it is the most useful cryptography bitcoin has added.

Start with the cost of holding coins across several devices. A 2-of-3 arrangement spent the old way publishes two signatures and three public keys in every transaction, so you pay for the whole policy each time you move funds. Spent cooperatively through Taproot it publishes one signature, and the other keys never appear. The saving compounds if you consolidate small amounts, which is exactly what long term holders end up doing.

Then the privacy consequence, which is larger. Chain analysis firms classify addresses by shape, and multisig has always been a loud shape. The hardware wallets we review can act as co-signers in arrangements like this, and until Taproot the act of protecting yourself properly told observers you had something worth protecting. A cooperative Schnorr spend removes that tell without weakening anything.

For an inheritance plan the calculation shifts too. Because unused branches of a Taproot tree cost nothing, you can add a time delayed recovery path for a family member without paying for it on every ordinary spend. That is a genuinely new option, and it is worth reading our security guide before designing one, because the failure mode of a clever custody scheme is losing access rather than being robbed.

MuSig2: two signers, one signature

MuSig2, standardized as BIP-327, is the protocol that turns linearity into something wallets can actually use.

Naively adding public keys together is unsafe. If one participant learns everyone else's key before announcing their own, they can craft a key that cancels the others out and end up able to sign alone. This is the rogue key attack, and MuSig2 defeats it by weighting each key with a coefficient derived from the whole set, so no participant can choose theirs freely.

The signing flow is two rounds. Each party sends nonce commitments, then each party sends a partial signature, and the partials add up to one valid Schnorr signature under the aggregated key. Two rounds matter because the first can be done in advance, which is what makes the scheme usable in Lightning channels where signatures are exchanged constantly.

What lands on-chain is a single 64 byte signature spending a single key path output. A cooperative two party spend costs about 57.5 vbytes, less than any other input type, and the observer cannot tell whether one person or a committee authorized it.

Schnorr signature vs signature

On bitcoin the bare word signature still usually means ECDSA, and both schemes are in daily use. Coins sitting at an address beginning 1, 3, or bc1q are spent with ECDSA, exactly as they were in 2010. Coins at a bc1p address are spent with Schnorr. A wallet holding both, which most wallets with any history do, produces both kinds in the same session without mentioning it. Anyone telling you bitcoin uses ECDSA, full stop, is describing the protocol as it stood before November 2021.

Schnorr signature vs MuSig2

Schnorr is the signature scheme; MuSig2 is one protocol built on top of it. You can use Schnorr with a single key forever and never touch MuSig2, which is what every ordinary Taproot wallet does today. MuSig2 only enters when several parties want to look like one, and it is not the only option built on the same property: threshold schemes that tolerate a missing signer, and adaptor signatures used for atomic swaps and Lightning, are separate constructions drawing on the same linearity.