Schnorr Signature

Alice wants to send bitcoin to Bob. A wallet is an application or device for receiving and sending bitcoin. Her wallet builds a transaction and uses her private key to sign the data required by its signing mode. A node then verifies the signature and all the other spending conditions. A node is software that checks transactions and blocks and communicates with other participants in the network. A valid signature alone does not establish Alice’s legal identity, confirm the intended recipient or prove that enough unspent funds exist; these are separate questions. A signed payment can still be a mistake Alice never meant to make. [5] [3] [10] [11]

BIP340, by Pieter Wuille, Jonas Nick and Tim Ruffing, precisely defines Bitcoin’s Schnorr signature. BIP341 incorporates it into Taproot’s spending rules, which activated on Bitcoin’s main network (Mainnet) at block 709632 in 2021. A block groups transactions into a batch added to the shared history. These are two layers: the signature algorithm and the spending conditions. Older outputs and SegWit v0 still use ECDSA, the older signature algorithm; the upgrade did not retroactively rewrite their signatures. [1] [2] [11]

A byte is a standard unit of data size. The Bitcoin variant uses the secp256k1 elliptic curve, a mathematical structure for working with keys and signatures. BIP340 specifies a fixed 64-byte signature format. A public key is encoded as the 32-byte x coordinate; x-only does not mean skipping a security check. The rules also unambiguously determine which version of the curve point a verifier must use. A smaller, precisely defined format helps software, but these two numbers alone do not tell you the size of a whole transaction. [1] [12]

A wallet does not sign a vague “I agree”. The sighash mode determines which transaction data form the signed message. SIGHASH_DEFAULT protects information about all inputs and all outputs, similarly to SIGHASH_ALL: which previously received coins are spent and which new amounts with spending conditions are created. Changing covered data invalidates the signature. This does not mean signing every byte, such as the other signatures. Other permitted modes protect a different scope. The signature itself is 64 bytes; a non-default mode appends a type byte, making that item 65 bytes. That is still not the size of the entire input or transaction. [2]

Signing creates a secret nonce value. Reusing it for different messages with the same key can reveal the private key. BIP340 therefore specifies nonce derivation precisely and recommends auxiliary random data as additional protection for the implementation. Users do not invent a nonce or write it into their backup. A vetted signing library manages it; improvising here can defeat otherwise sound cryptography. [1] [9]

The mathematical structure of Schnorr signatures allows protocols in which several people agree on a message and produce a joint signature. MuSig2, specified in BIP327, is one example. In the basic form of this protocol, every member of the chosen group must contribute. It requires coordination, correct key handling and its own safe nonce procedure. Simply adding arbitrary completed signatures is not enough. A wallet’s support for Schnorr Signature does not, by itself, mean it supports this collaboration. [8]

Taproot offers different spending paths. With a key path, the network checks a signature against the public key recorded in the output. That key can represent one person or a cooperating group. With a script path, the chosen script is revealed: a program containing conditions the payment must satisfy. Tapscript is the version of this scripting language used by Taproot. Its OP_CHECKSIGADD instruction checks one signature and, on success, adds one to a running total. Repeating it can evaluate several separate signatures against a required count. This form of script-based Multisig differs from one aggregate signature. For a particular wallet, check who must cooperate, what becomes public and what recovery remains possible if a key is lost. [7] [2]

In a network without a central referee, one node must not accept a signature that another rejects because it interprets the bytes differently. BIP340 therefore specifies valid keys, signatures and the verification procedure in detail. It also supports batch verification: checking several signatures together to save computation. This does not rewrite their blockchain records or combine signatures from different transaction inputs. [1]

A joint key-path signature can look like a signature from a single key. The signature alone may therefore not reveal how many people agreed. Amounts, connections between inputs and outputs, and transaction timing generally remain observable. Schnorr Signature does not encrypt a payment. The privacy outcome also depends on how Taproot is used, the wallet’s behavior and the payment’s circumstances. [2] [3]

For an everyday user, what matters is a wallet that correctly displays the recipient, amount and fee and supports reliable recovery. A developer must also check precise BIP340 support, test vectors, nonce handling and failure behavior. An algorithm’s name does not guarantee the whole product. A good library, such as libsecp256k1, handles the cryptographic computation; it cannot decide whether a person should approve the payment on screen. [4] [9] [6]