A digital signature is a specific piece of data that proves two things at once: that a specific message was authorized, and that the authorizer had access to a specific private key — without revealing the private key. Every crypto transaction that has ever moved funds included a signature. Understanding what the signature proves, and how, is central to understanding why crypto wallets can be self-custodial in the first place.
What a signature actually is
A signature is a piece of data — typically 64-72 bytes — attached to a message. The signature is produced by a signing algorithm that takes as input the message and the private key. Anyone can verify the signature by running a verification algorithm with the message, the signature, and the corresponding public key. The verification returns true or false.
Two properties matter:
**Unforgeable without the private key**: no one can produce a valid signature for a specific message without the corresponding private key. The math makes this the case unconditionally — not merely difficult, but computationally infeasible.
**Bound to the specific message**: a signature over "send 1 BTC to Alice" is not valid for "send 1 BTC to Bob." The signature verifies against the exact message it was created for.
These two properties combined mean: seeing a valid signature proves that the private-key-holder authorized this exact message. This is what a Bitcoin transaction relies on. When your wallet signs a transaction, it proves you (or whoever has your private key) authorized this specific transfer.
ECDSA: the standard
ECDSA — Elliptic Curve Digital Signature Algorithm — has been the workhorse for Bitcoin, Ethereum, and most other cryptocurrencies since inception. It is based on the mathematical difficulty of the elliptic-curve discrete logarithm problem: given a public key (a point on the elliptic curve), you cannot compute the private key (the number that was multiplied to reach that point).
ECDSA signatures are about 71-73 bytes long in Bitcoin's DER encoding. The algorithm has been well-studied and no practical break exists.
Ecosystem-wise, ECDSA is universal — every hardware wallet, every library, every implementation supports it. It is boring, mature, and works.
The problems with ECDSA
ECDSA has three quirks that motivated Bitcoin's move to Schnorr:
**Malleability**: for a given valid signature, small transformations can produce another valid signature over the same message. This does not let an attacker forge signatures, but it lets them slightly modify a transaction's ID (the hash of the whole transaction including its signature). This caused real problems in the pre-SegWit era.
**No native multi-signature aggregation**: ECDSA multisig requires each signer to produce a separate signature, and the transaction includes all of them. A 3-of-5 multisig transaction is significantly bigger and more expensive than a single-sig transaction.
**Randomness dependency**: ECDSA signing requires a fresh random number per signature. If the random number is reused or predictable, the private key can be extracted from just two signatures. This has caused real key compromises historically (the PlayStation 3 keys were extracted this way, and some poorly-implemented crypto wallets have had similar issues).
None of these are fatal for ECDSA in practice — Bitcoin has run on ECDSA for over a decade without systemic issues. But they left room for improvement.
Schnorr signatures
Schnorr signatures are a different scheme, also based on elliptic-curve math but with a cleaner internal structure. They solve all three ECDSA quirks:
**Non-malleable by design**: the signature format admits no alternative valid signatures over the same message.
**Native aggregation**: multiple Schnorr signers can combine their signatures into a single aggregated signature. A 3-of-5 multisig with Schnorr looks on-chain like a single-signature spend, both in size and in appearance. This is a huge efficiency win.
**Deterministic option**: Schnorr can be implemented in a deterministic mode (via RFC 6979-style derivation of the nonce from the private key and message), eliminating the random-number-generator failure mode.
Schnorr was known to be superior to ECDSA for decades but was patent-encumbered until the early 2010s. By the time Bitcoin considered adding it, the tech was proven; the delay was purely about getting it into the network safely.
Taproot and Schnorr in Bitcoin
Taproot activated on Bitcoin in November 2021 and included Schnorr signature support (BIP-340) as one of its three main features. Taproot addresses (bc1p prefix) can spend using Schnorr signatures instead of ECDSA.
For single-signature spending, Taproot Schnorr and Native SegWit ECDSA look virtually identical in cost and behavior — the signature is a few bytes smaller with Schnorr.
For multi-signature and script-heavy spending, Taproot Schnorr is dramatically better. A 3-of-5 multisig spend using Schnorr aggregation looks identical to a single-signature spend to the outside world — same size, same appearance, same cost. All the multisig complexity happens off-chain, before the aggregated signature is produced.
This makes Taproot the right choice for anyone doing multisig, and by extension the right default for institutional custody, exchange treasury management, and any use case where privacy of the spending policy matters.
Ethereum's stance
Ethereum has stayed with ECDSA — every account uses ECDSA signatures, every wallet signs with ECDSA. There are periodic discussions about adding Schnorr or BLS signatures at the protocol level, but no serious plan.
Account Abstraction (ERC-4337) opens the door to any signature scheme at the smart-contract level. A smart-contract account can verify Schnorr, BLS, post-quantum, or any other signature type in its verification code. This is how Ethereum can add new signature schemes without a protocol change — via the account layer.
For actually deployed EOA (externally-owned account) wallets, ECDSA is what you use. For smart-contract accounts and future ERC-4337 setups, the signature scheme is a design choice per contract.
Signature aggregation across signers
The Schnorr aggregation property matters most for multisig. But it also enables an interesting class of new possibilities:
**MuSig / MuSig2**: multi-party protocols that let a group jointly produce a Schnorr signature that verifies against an aggregated public key. Externally, the multisig is indistinguishable from a single-key spend.
**FROST**: threshold Schnorr signatures — the multi-party equivalent of a Schnorr multisig, but with any threshold (t-of-n) and no need for a trusted setup.
These primitives make privacy-preserving multisig practically deployable. Lightning channels, DAOs, exchange treasuries — anywhere multiple parties need to sign together — can potentially use these techniques to look like a single signer on-chain.
What signatures do not prove
A signature proves the message was authorized. It does not prove:
- The signer wanted to sign what they thought they were signing (see: signing a malicious transaction that looked benign in a fake wallet UI)
- The signer was not coerced (a valid signature does not prove voluntary consent)
- The message content is correct or beneficial
Every real crypto theft comes from getting the user to sign something they thought was different. The signature scheme is not at fault; the user's interpretation of what they were signing was. This is why wallet UX around signing is so important, and why anti-phishing tools (Rabby-style transaction pre-simulation) matter more than the signature scheme itself.
Practical takeaways
- Every Bitcoin wallet older than Taproot uses ECDSA. Every Ethereum wallet uses ECDSA. That is fine — ECDSA works.
- Every Taproot Bitcoin wallet can use Schnorr, and modern wallets do by default. The benefits are cleaner multisig and marginal fee savings.
- Multisig setups should strongly prefer Taproot Schnorr where all hardware wallets support it. The privacy and cost gains are meaningful.
- Signature security failures come from bad randomness (a real issue historically), key leakage (obvious), and user error (signing the wrong thing). The math is not the failure mode.
The signature is the moment a private key produces public authorization. It is the atomic unit of what crypto wallets do. Understanding what it proves — and what it does not — is core literacy for anyone thinking seriously about self-custody.
