Glossary / Transactions & fees
Digital signature
Also known as Signature, ECDSA signature.
- Definition
- A digital signature is the proof, produced with a private key, that whoever authorized a bitcoin transaction controlled the key its coins were locked to, and that the details have not been altered.
Bitcoin is no longer ECDSA only. Coins at addresses starting 1, 3, or bc1q are unlocked with ECDSA signatures of 71 or 72 bytes; coins at bc1p addresses use 64 byte Schnorr signatures, live since November 2021. Either way the signature proves control of a key, and never proves who the person is.
How it works
Producing a signature takes three ingredients: a private key, a one-time random number called a nonce, and a digest of the transaction as trimmed by the flag chosen for that input.
The result is a pair of numbers computed on secp256k1, the elliptic curve bitcoin has used since its first release. Verification runs the same arithmetic in reverse using the public key, and a node performs it inside the script opcode OP_CHECKSIG. Nothing is encrypted at any stage, and the signature discloses nothing about the private key behind it.
The two schemes in use package that pair differently. An ECDSA signature is wrapped in DER, which is why it comes to 71 or 72 bytes rather than a fixed length, and the final byte is not part of the signature at all: it is the flag stating which parts of the transaction were covered. A Schnorr signature under BIP340 is a flat 64 bytes with no wrapper, and the flag byte is left out entirely when the default applies, so 65 bytes appears only when a signer wants something unusual.
The nonce is the part that goes wrong. Use the same one twice with the same key and the private key falls out with school algebra, which is not a theoretical worry: on August 11, 2013 bitcoin.org published an advisory about an Android flaw that made wallet apps on affected phones generate repeating values, and coins were stolen as a result. Wallets now derive the nonce deterministically from the key and the message, following RFC 6979 for ECDSA and an equivalent rule inside BIP340.
Where you see it
Every spend you make contains at least one. On a block explorer it is the long hexadecimal string in a segwit input's witness or in a legacy input's unlocking script, and the trailing 01 on the ECDSA ones is the flag, not part of the mathematics.
Signatures also work away from transactions. Signing a plain message with the key behind an address proves you control that address without moving a satoshi, which is how exchanges verify a withdrawal destination, how proof of reserves attestations are assembled, and how a seller on a peer-to-peer marketplace shows an address really is theirs. The original format only worked for addresses beginning with 1; BIP322 generalizes message signing to every address type in use today.
That distinction matters whenever someone asks you to sign something. A signed message cannot move coins. A signature over a transaction can move all of them, and the only dependable way to tell which one you are being asked for is to read your hardware wallet's screen rather than the website's.
Digital signature vs signature hash
The signature hash is the input; the signature is the output. Your wallet first builds a digest covering a specific subset of the transaction, then signs that digest, so the signature says nothing whatsoever about the parts the digest left out. This is not a technicality. It is the entire reason the sighash flags exist, and it explains how two signatures on one transaction can be protecting completely different things.