Schnorr signatures

A signature proves that whoever holds a private key approved one exact message, without revealing the key. Change a single bit of the message and the signature stops being valid.

Pearl signs every spend with Schnorr signatures as defined in Bitcoin’s BIP-340. They are short (64 bytes), simple, and built on the elliptic-curve arithmetic from the previous page.

Try it

Sign a message, verify it, then flip one bit and watch verification fail.

What’s inside a signature?

Two 32-byte numbers, back to back. Here is a real BIP-340 signature made with Pearl’s own code, for the message SHA-256(“Pearl”), with BIP-340’s optional extra randomness set to the number 1:

(This test key is public. Never use it for real coins.)

How is a signature made?

With private key d and public key P = d·G:

1. Pick a secret nonce

   Choose a one-time secret number k, the signing nonce, and compute the point R = k·G.

2. Make the challenge

   Hash R’s x-coordinate, the public key and the message with the BIP0340/challenge tagged hash. Read the result as a number e.

3. Mix the key in

   Compute s = k + e·d, modulo the curve’s order n. The signature is (R.x, s).

The nonce hides the key: s mixes d with a random-looking k, so s alone says nothing about d. The challenge ties everything to this message and this key.

How is it checked?

The verifier knows P, m and the signature, so it can recompute e. It does not know k or d. It checks one equation:

Only someone who knew d could have produced an s that makes both sides match.

Why must the nonce never repeat?

Because two signatures with the same k give the key away. Subtract them:

Everything except d is public, so d = (s₁ − s₂) / (e₁ − e₂). The same happens if k is ever guessable. This has drained real wallets on other chains.

BIP-340 suggests deriving k from the private key, the message and some fresh randomness. Pearl’s transaction signer, inherited from btcd, derives it deterministically with RFC 6979 instead: the same key and message always give the same k, and a different message always gives a different one.

Both methods give valid BIP-340 signatures, and a verifier can’t tell them apart. For the key and message above, Pearl’s default signer produces a different but equally valid signature, starting c3a52ccdb5b9875d….

Where do signatures appear in a Pearl transaction?

In the witness. A normal Pearl spend uses the Taproot key path, and its whole witness is a single 64-byte Schnorr signature (65 bytes if it names a sighash type other than the default).

The message being signed isn’t the raw transaction. It’s a 32-byte digest built with the TapSighash tagged hash, covering the inputs, outputs and amounts. See sighash.

In this real payment, the witness is one item of 40 (64) bytes: R.x = 4686c7014749649b…1ebcdc82a2, then s = 2d74ce1a1671d028…6be7a86ba2.

Why Schnorr rather than ECDSA?

Schnorr signatures are linear: the equation s = k + e·d adds up nicely. That makes several things possible that ECDSA makes hard:

• Key aggregation. Several people can combine keys and produce one ordinary-looking signature (MuSig2).
• Batch verification. Many signatures can be checked together, faster than one by one.
• A clean security proof, and a fixed 64-byte size with no special encoding.

import { schnorr } from '@noble/curves/secp256k1.js';

const sig = schnorr.sign(msg32, privKey, auxRand);   // 64 bytes: R.x ‖ s
schnorr.verify(sig, msg32, xOnlyPubKey);             // true
msg32[31] ^= 1;
schnorr.verify(sig, msg32, xOnlyPubKey);             // false: one bit changed