Signature schemes: ECDSA, Schnorr, EdDSA and BLS

What a signature proves, and what it does not

A digital signature scheme is three algorithms: key generation, signing and verification. The security goal is existential unforgeability under chosen message attack: an attacker who can ask for signatures on any messages still cannot produce a valid signature on a new one. Chains want a little more. Strong unforgeability also forbids producing a second valid signature on an already signed message, which is exactly the property ECDSA lacks. A signature proves that the holder of a key approved a specific byte string. It does not prove they understood it, which is why reading what you sign matters as much as the mathematics.

All four schemes here work in a cyclic group of large prime order n with generator G. A private key is a scalar d and the public key is the point Q = d·G. Security rests on the discrete logarithm problem: given Q, finding d takes about √n group operations with the best generic attack (Pollard’s rho), so a 256 bit group offers about 128 bits of security.

The curves in production

BN254 deserves a caveat. Advances in the number field sieve since 2016 cut its estimated security well below the 128 bits it was designed for; EIP-2537 cites about 80 bits, and other published estimates put it nearer 100. It remains in use because its precompiles have existed since 2017. BLS12-381 was designed with those attacks in mind, and EIP-2537 cites 120 plus bits.

ECDSA on secp256k1

To sign a message hash z with key d, pick a fresh secret nonce k, then:

Ethereum adds a recovery id. Given r and s there are generally two candidate points R (two y values for one x), so a single bit, the parity of R_y, selects the right one, and from it the public key can be computed: Q = r⁻¹( s·R − z·G ). That is why an Ethereum transaction carries no public key. The sender’s address is the last 20 bytes of keccak256 of the recovered key. Legacy transactions encode the bit as v = 27 or 28, EIP-155 transactions as v = chainId × 2 + 35 or 36, which also binds the signature to one chain, and typed transactions carry a plain yParity of 0 or 1. Contracts get the same recovery from the ecrecover precompile at 0x01 for 3,000 gas.

Malleability and low s

If (r, s) is valid, so is (r, n − s): negating s corresponds to negating k, which gives the point −R with the same x coordinate. Anyone can flip a signature without the key. In Bitcoin this let third parties change a transaction’s ID before confirmation, which broke software that tracked payments by txid. The fixes came in layers: strict DER encoding (BIP 66), a relay policy that accepts only low s, and SegWit, which moved signatures out of the txid entirely. Ethereum made high s transactions invalid in the Homestead upgrade of 2016 (EIP-2), but the ecrecover precompile deliberately still accepts both forms. A contract that treats signature bytes as unique, for example by storing used signatures to prevent replay, can therefore be replayed with the twin:

// ecrecover accepts both (r, s) and (r, n - s), and returns address(0) on failure.
uint256 constant HALF_N =
    0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0;

function recoverSigner(bytes32 digest, uint8 v, bytes32 r, bytes32 s)
    internal pure returns (address signer)
{
    require(uint256(s) <= HALF_N, "high s");     // reject the malleable twin
    require(v == 27 || v == 28, "bad v");
    signer = ecrecover(digest, v, r, s);
    require(signer != address(0), "bad signature");
    // Replay protection belongs in the digest (nonce, chainid, contract address),
    // never in the signature bytes, which are not unique.
}

Audited libraries such as OpenZeppelin’s ECDSA helper perform these checks. The deeper rule is to key replay protection on the signed digest, with a nonce, the chain ID and the verifying contract inside it. The vulnerability classes guide covers the replay family in full.

Nonces: the single point of failure

The nonce k must be secret, uniform and never reused. Two signatures with the same k on different messages leak the key with high school algebra:

# Two ECDSA signatures that share r were made with the same nonce k.
# Everything used below is public: r, both s values and both message hashes.
n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141  # secp256k1 order

def recover_private_key(r, s1, z1, s2, z2):
    k = (z1 - z2) * pow(s1 - s2, -1, n) % n     # s1 - s2 = k^-1 (z1 - z2)
    d = (s1 * k - z1) * pow(r, -1, n) % n       # s1 = k^-1 (z1 + r d)
    return d
# If a signer normalized either s to n - s (low s), also try those sign combinations.

This is not hypothetical. Sony signed PlayStation 3 software with a fixed ECDSA nonce, and at the Chaos Communication Congress in December 2010 the fail0verflow team showed how that exposed Sony’s private signing key. In August 2013 a weakness in Android’s secure random number generator put every Android Bitcoin wallet app at risk, and coins were stolen from addresses whose signatures repeated nonces. Even partial leakage is fatal: a few biased bits per nonce across enough signatures let lattice techniques recover the key.

The standard defense is RFC 6979 (August 2013), which derives k deterministically from the key and the message hash with HMAC-DRBG, so the same message always yields the same signature and different messages never share a nonce. BIP 340 goes a step further with a synthetic nonce: a hash of the key, the message and fresh auxiliary randomness, which stays safe if the randomness is bad and adds protection against fault attacks if it is good.

Schnorr and BIP 340

Schnorr signatures are simpler and, unlike ECDSA, linear in the secret. The Bitcoin version, BIP 340, uses 32 byte x-only public keys, 64 byte signatures and tagged SHA-256 hashes that separate every use:

BIP 340 went live with Taproot (BIPs 340, 341 and 342), which activated at block 709,632 on November 14, 2021. Its signatures are provably non-malleable, have a fixed size, and can be batch verified: checking many signatures at once is substantially faster than checking each alone.

Linearity, rogue keys and MuSig2

Because s is linear in d, two signers can add partial signatures and get one signature that verifies against the sum of their keys. Done naively this is broken. If Alice announces P_A, Mallory announces P_M = X − P_A for a key X she controls, and the "joint" key P_A + P_M = X is hers alone. MuSig fixes this by weighting each key with a hash of the whole key set, a_i = H(L, P_i). MuSig2 (BIP 327) does it in two rounds, and the first round, exchanging nonces, can happen before the message is known. Each signer contributes two nonces, combined with a message dependent coefficient, which defeats the concurrent session attacks that broke earlier two round designs.

The payoff shows up onchain. A MuSig2 aggregate key can be a Taproot internal key, so an n of n spend is a single 64 byte signature that looks exactly like any other key path spend. Threshold policies go in the script tree, where Tapscript’s OP_CHECKSIGADD replaces the retired OP_CHECKMULTISIG, or into FROST, covered in multisig, MPC and threshold signatures.

EdDSA and Ed25519

Ed25519, specified in RFC 8032 (January 2017), is Schnorr on edwards25519 with the nonce derived by hashing a secret prefix of the expanded key together with the message:

Deterministic nonces remove the RNG failure class, and the complete Edwards addition formulas make fast constant time code easier to write. The subtle part is the cofactor of 8. Libraries have disagreed on edge cases such as small order points, non canonical encodings and whether to multiply the verification equation by 8, so the same signature can be valid in one implementation and invalid in another. For a consensus system that disagreement is a chain split, which is why Zcash pinned exact rules in ZIP 215 (2020). Anyone building a verifier that must agree with a chain should match that chain’s library bit for bit.

On Solana every account key is an Ed25519 key, and a program derived address is deliberately a point that is not on the curve, so no private key for it can exist and only the owning program can sign for it. The Solana runtime guide shows how that is used.

BLS on BLS12-381: signatures that add up

BLS signatures use a pairing e: G₁ × G₂ → G_T, a bilinear map with e(a·P, b·Q) = e(P, Q)^ab. Ethereum uses the variant with public keys in G₁ (48 bytes) and signatures in G₂ (96 bytes):

Aggregation is noninteractive: anyone can add signatures, σ = ∑σ_i. When all signers signed the same message, verification needs only the sum of their public keys, which is cheap point additions, and two pairings, however many signers there are. That is the whole reason the beacon chain uses BLS. Every validator attests once per epoch, committees of up to 2,048 are aggregated slot by slot, and since Pectra (EIP-7549) the committee index sits outside the signed data, so identical votes aggregate across committees. The EIP computes the effect: on a large validator set, the minimum number of aggregates needed to see a 2/3 supermajority in an epoch fell from 1,366 to 22.

The rogue key attack from the Schnorr section applies here too, and Ethereum closes it with proof of possession: the ciphersuite is the POP variant, and every validator deposit is signed by its own key. The costs are pairings, which are far slower than a Schnorr verification, and a heavier curve. Uniqueness has a bonus: the RANDAO reveal each proposer publishes is a BLS signature over the epoch number, so it is unpredictable to others yet fixed for the proposer. Since Pectra, EIP-2537 exposes BLS12-381 operations to contracts at 0x0b to 0x11, with a pairing check priced at 32,600 per pair plus 37,700 gas.

secp256r1 and passkeys

Passkeys, WebAuthn and the secure enclaves in phones and laptops sign with ECDSA on P-256, not secp256k1. The Fusaka upgrade (December 2025) added a P-256 verification precompile at 0x100 through EIP-7951, priced at 6,900 gas, double the 3,450 of the earlier RIP-7212 precompile that many rollups adopted. Ordinary accounts still sign with secp256k1, so passkeys reach Ethereum through smart accounts: the account contract verifies the passkey signature, as described in account abstraction internals. One practical trap: WebAuthn signs authenticator data plus a hash of client data that embeds the challenge, not the raw transaction hash, so the verifier has to parse that structure and check the challenge itself. Some cryptographers distrust the unexplained seeds behind the NIST curve constants; no weakness has been shown.

The four schemes compared

The post quantum outlook

Shor’s algorithm solves the discrete logarithm problem in polynomial time on a large fault tolerant quantum computer, which breaks every scheme in this guide, pairing based ones included. Hash functions only lose to Grover’s quadratic speedup. No machine capable of this is publicly known as of September 2026, and estimates of when one might exist vary widely, so the engineering question is migration, not panic.

NIST published ML-DSA (FIPS 204, lattice based) and SLH-DSA (FIPS 205, hash based) on August 13, 2024. Size is the obstacle for blockchains:

Exposure depends on whether a public key is visible. A hashed address hides the key until its first spend, while reused addresses, pay to public key outputs and Taproot key paths expose one permanently. On the research side, BIP 360 (still a draft) proposes Pay to Merkle Root, a Taproot style output without the key path, as a first step against long exposure attacks, and the Ethereum Foundation’s lean Ethereum vision (July 2025) plans hash based aggregate signatures to replace BLS in consensus. Accounts that are smart contracts can change their signature scheme without changing their address, one of the stronger arguments for account abstraction.

Common questions

Where to go next