Digital Signature

What Is a Digital Signature?

A digital signature is a mathematical scheme that proves the authenticity and integrity of a message or transaction. In Bitcoin, every time you spend funds, your wallet produces a digital signature that proves you own the private key associated with the address holding those funds. The signature is specific to the transaction data: changing even a single byte of the transaction would invalidate it.

Unlike a handwritten signature that looks the same every time, a digital signature is unique to both the signer and the message being signed. This means two transactions from the same wallet produce completely different signatures, yet both can be verified using the same public key. The underlying math relies on the secp256k1 elliptic curve, where deriving the private key from a public key is computationally infeasible.

How It Works

Every Bitcoin digital signature involves three elements: a private key (known only to the signer), a public key (derived from the private key and shared freely), and the message being signed (typically a transaction hash). The process has two phases: signing and verification.

Signing

1. The wallet computes a hash of the transaction data (the specific portions determined by the sighash flag)
2. A fresh random value called a nonce is generated for this signature
3. The nonce, transaction hash, and private key are combined through elliptic curve math to produce the signature values (r, s)
4. The signature is attached to the transaction input, proving authorization

Verification

1. A node receives the transaction with its signature
2. Using only the public key, the signature, and the transaction data, the node performs a mathematical check
3. If the check passes, the node confirms that the holder of the corresponding private key authorized the transaction
4. The private key is never revealed during this process: that is the core property of public-key cryptography

ECDSA: The Legacy Signature Scheme

Bitcoin originally used ECDSA (Elliptic Curve Digital Signature Algorithm) on the secp256k1 curve. ECDSA remains the signature scheme for all legacy, P2WPKH, and P2WSH transactions.

ECDSA Signature Details

An ECDSA signature consists of two 32-byte integers, r and s. These are DER-encoded for inclusion in transactions, resulting in a variable size:

The variable signature size comes from DER encoding rules: if either r or s has a high bit set, a padding byte is added. Since Bitcoin Core v0.17.0 (2018), wallets use "nonce grinding" to produce only 71-byte signatures by re-signing until a low r-value is found.

Schnorr: The Taproot Signature Scheme

Schnorr signatures, specified in BIP 340 and activated with the Taproot soft fork at block 709,632 on November 14, 2021, offer significant improvements over ECDSA. For a deeper exploration, see the Taproot and Schnorr signatures deep dive.

Schnorr Signature Details

The linearity of Schnorr's equation (s = k + ed) is the key advantage. Because the equation is linear, multiple signatures and public keys can be combined algebraically: a property that is mathematically impossible with ECDSA's non-linear structure.

Key Aggregation with MuSig2

Schnorr's linearity enables MuSig2 (BIP 327), a protocol where multiple signers produce a single 64-byte aggregate signature and a single 32-byte aggregate public key. On-chain, this looks identical to a standard single-key P2TR spend: there is no way for an observer to distinguish a 3-of-3 multisig from a solo spend. This improves both privacy and efficiency compared to legacy multisig, which requires separate public keys and signatures for each signer.

Batch Verification

When validating a block, nodes must verify every signature in every transaction. Schnorr signatures can be verified in batches using multi-scalar multiplication, checking many signatures together rather than one at a time. Benchmarks show approximately 16% faster block validation for fully Schnorr-signed blocks. As Taproot adoption grows, batch verification will provide increasingly meaningful speedups during initial block download.

Sighash Flags

A sighash flag is a single byte appended to each signature that controls which parts of the transaction the signature commits to. This determines what can and cannot be modified after signing.

Nearly all Bitcoin transactions use SIGHASH_ALL, which locks the entire transaction. The ANYONECANPAY modifier enables crowdfunding-style transactions where multiple parties can add inputs to a transaction with a fixed set of outputs.

The Nonce: A Critical Security Parameter

Every digital signature requires a fresh nonce (a random number used once). The nonce creates randomness so that signing the same transaction twice produces different signatures. If an attacker discovers the nonce, they can compute the private key directly.

Reusing the same nonce for two different signatures is catastrophic. Given two signatures (r, s₁) and (r, s₂) that share the same r value (because they share the same nonce k), an attacker can recover k through simple arithmetic, then derive the private key from either signature. In 2013, a flawed random number generator in Android caused nonce reuse in Bitcoin wallets, allowing attackers to drain affected addresses.

Modern wallets prevent this by using deterministic nonce generation (RFC 6979 for ECDSA, and tagged hashing for Schnorr in BIP 340). Instead of relying on random number generators, the nonce is derived from the private key and the message hash. This guarantees a unique nonce for every unique message while eliminating reliance on the system's random number generator.

Use Cases

Transaction Authorization

The primary use of digital signatures in Bitcoin is proving ownership of funds. Every UTXO is locked to a public key (or script), and spending it requires a valid signature from the corresponding private key. Without a valid signature, the network rejects the transaction.

Multi-Party Protocols

Schnorr signatures power advanced multi-party protocols. With MuSig2, multiple parties collaboratively sign a transaction while producing a single compact signature. FROST threshold signatures extend this to t-of-n schemes, where any t participants out of n can produce a valid signature. These protocols enable efficient collaborative custody without the on-chain overhead of traditional multisig.

Layer 2 Protocols

Off-chain protocols like the Lightning Network and Spark rely heavily on digital signatures. Lightning uses pre-signed transactions to enforce channel state, while Spark uses FROST signatures across its operator network to manage off-chain transfers securely.

Risks and Considerations

Private Key Compromise

A digital signature is only as secure as the private key behind it. If an attacker gains access to the private key (through malware, phishing, or poor key storage), they can produce valid signatures and steal funds. Hardware signing devices and proper key management practices mitigate this risk.

Signature Malleability

ECDSA signatures have a malleability issue: given a valid signature (r, s), the value (r, n - s) is also valid. This allowed third parties to modify transaction IDs without invalidating the transaction, which caused problems for protocols tracking transactions by their txid. SegWit resolved this by moving signatures to the witness section, and Schnorr eliminates malleability entirely by design.

Quantum Computing Threat

Shor's algorithm, if run on a sufficiently large quantum computer, could derive a private key from a public key, breaking both ECDSA and Schnorr. This threat has motivated research into post-quantum signature schemes. BIP 360, merged in February 2026, introduces a Pay-to-Merkle-Root output type as a foundation for future quantum-resistant upgrades. Candidate algorithms like SLH-DSA produce signatures of approximately 8 KB or more, compared to Schnorr's 64 bytes: a significant tradeoff between security and block space efficiency. Current expert consensus places viable quantum attacks beyond 2030 at the earliest.

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.