BIP 458 merged: half-aggregation would shrink n Schnorr signatures from 64n to 32n + 32 bytes
Victoria Shinder2 min readThe BIPs repository merged pull request 2205 on 2 November, adding BIP 458, Half-Aggregation of BIP 340 Signatures. The document, by Tim Ruffing, Jonas Nick and Fabian Jahr, carries the status Draft and the type Specification, was assigned its number on 2 July 2026, and ships with a Python reference implementation and test vectors.
Half-aggregation compresses a collection of BIP 340 Schnorr signatures into a single aggregate signature about half their combined size: n signatures take 64 times n bytes, while their half-aggregate takes 32 times n plus 32. The process is a pure function of the signatures, public keys and messages, and it is non-interactive, so neither the signers nor the verifier have to cooperate. That separates it from MuSig2 in BIP 327, where signers work together to produce one signature under one aggregate key. Here there is no aggregate key; the verifier checks the aggregate against each individual key and message. The specification also defines an incremental form that adds more signatures to an existing aggregate.
The authors give two example uses. One is the Lightning Network's routing gossip, which today carries ECDSA signatures: if it moved to BIP 340, nodes could batch messages and half-aggregate their signatures. The other is inside Bitcoin's consensus protocol, where the idea has been discussed before. The BIP deliberately leaves the trade-offs of each application to other documents, and its reference code is marked as not for production use.
What it means
A merged BIP is a specification, not a change to Bitcoin. Nothing here alters transactions or blocks; using half-aggregation in consensus would need its own soft fork proposal and wide agreement. What the merge does is give implementers one agreed definition and shared test vectors, which is the step that has to come before any protocol can rely on the scheme.