After recently watching Tim Ruffing's Eurocrypt talk about signature aggregation -#1518433 - this BIP draft by Fabian Jahr caught my eye.

This document describes full-aggregation of BIP 340 signatures, a standard for the DahLIAS^[1] interactive aggregate signature scheme. Full-aggregation is an interactive process for aggregating a collection of signatures into a single aggregate signature. The resulting aggregate signature has the same size as a single BIP 340 signature (64 bytes), regardless of the number of signers.

You may recall that while multisignature is multiple keys signing the same message, signature aggregation is a method for creating a single signature of multiple public keys signing for multiple different messages.

Unlike interactive multisignature schemes such as MuSig2 (BIP 327), in which signers cooperate to produce a single signature under a single aggregate public key for a single message, full-aggregation does not combine the signers' keys. Each signer signs their own message under their own public key, and the aggregate signature is verified against the list of individual public key and message pairs.

The more you think about something like this, the more interesting it becomes:

The primary purpose is to reduce the amount of data sent to the verifier. While n BIP 340 signatures are 64n* bytes, a fully aggregated signature is always 64 bytes. Verifying the aggregate is also faster than verifying each signature separately. One application is cross-input signature aggregation (CISA) within the Bitcoin consensus protocol, which reduces the size and verification cost of multi-input transactions.

I believe there has also been some discussion about how signatures of this nature would greatly increase the ease with which coinjoins are performed. But, like coinjoins, the signature aggregation proposed here is interactive -- so you'd have to have a device with your keys online while creating the aggregated signature.

While this BIP proposes the design of such an aggregated signature scheme, it does not propose an implementation method -- but it requires a soft fork of some sort, which will no doubt be specified in a future BIP draft, similar to how BIP 340 (Taproot specification) and BIP 341 (Taproot implementation) work.

Another note here is that such aggregated signatures would still be vulnerable to quantum computers, should one powerful enough to break elliptic curve cryptography be built.