Batch verification

A verifier bundles u signatures, weights all but the first by a random scalar, and settles the bundle in one equation instead of u. BIP-340 was built for that, fixing signatures at 64 bytes, while standardized ECDSA cannot be batched at all unless extra witness data is added. Batching is each verifier's choice, so it changes how fast a node checks history and nothing about your coins.

How it works

Batch verification is specified in BIP-340 as BatchVerify, taking u 32-byte public keys, u messages and u 64-byte signatures and answering once for all of them.

The weights come first. The verifier generates u-1 integers in the range 1 to n-1, where n is the curve order, deterministically from a generator seeded by a hash of every input in the batch: keys, messages and signatures alike. BIP-340 calls SHA256 a safe seed hash and ChaCha20 a safe way to stretch it into 256-bit integers, skipping any that fall outside the range.

The batch then collapses into one test: the weighted sum of the s values, multiplied by the generator point, has to equal the same weighting applied to the R points and to each signature's challenge times its own public key. Those u separate checks become one comparison, which BIP-340 credits with significant speedups.

A per-signature cost buys that saving. BatchVerify lifts each r value back onto the curve, which single verification never does: Verify recomputes R from s and the challenge, then checks only that its x coordinate equals r.

The guarantee is deliberately asymmetric. If every signature in the batch is valid, BatchVerify always succeeds; if even one is invalid, it succeeds with at most negligible probability. What it will not do is name the offender, so a verifier that needs to know which signature broke checks them one at a time.

Where you see it

Batch verification lives entirely on the verifier's side of the network, which is why it never surfaces in a wallet interface or on a fee estimate.

Where it pays is a node working through years of Taproot spends at once, not a wallet sending a payment. BIP-340 mandates batching nowhere: single-signature verification is the definition, and a batch is something a verifier may choose. The BIP demands an algorithm specified at the byte level, the exactness DER parsing lacked until BIP-66, so nobody can build a signature valid to some verifiers and not others. Because the verifier picks its own batches, that property is what holds batch and single verification to differing only with negligible probability, even against an attacker trying to make them disagree.

Batching also explains choices inside BIP-340 that look arbitrary alone. Signatures could have taken a shorter form, one where a 16-byte hash suffices for the 128-bit security target, and the BIP turned it down: short hashes are fragile when distrusting signers work together, and the longer form carrying R is the one that supports batching. Public keys are 32 bytes rather than bitcoin's usual 33-byte compressed encoding, chosen for compactness, and the y coordinate that leaves out is pinned to the even one rather than left ambiguous, because efficient verification and batching both need it unambiguous.

ECDSA gets none of it. BIP-340 gives that as one reason to change the signature scheme: the standardized formulation cannot be verified more efficiently in batch than individually unless additional witness data is added.

Batch verification vs MuSig2

Batch verification and MuSig2 both make a pile of signatures cheaper, but only MuSig2 changes what gets broadcast.

MuSig2 aggregates several signers into one key and one ordinary 64-byte signature before the transaction reaches the network, so its saving is in privacy and block space, and it is n-of-n: every signer has to take part. Batch verification leaves each signature where it was and rearranges only the arithmetic a validator performs, with nobody's cooperation or even awareness: a node can batch signatures made by strangers years apart, in unrelated transactions.