Author: Kiara Bickers
Source: https://bitcoinmagazine.com/technical/not-ecdsa-not-schnorr-meet-dahlias
"Aggregate signatures" are not a new idea; they've been around since the early 2000s. However, developing a solution that could actually be used in Bitcoin's secure model, under Bitcoin's elliptic curve, has never been fully realized. Developers speculated that it was possible. They shared hand-drawn sketches and said, "Perhaps it would work similarly to ' MuSig2 ,' only across transaction inputs." This idea lingered as a developer's legend for years, but was never definitively proven.
But recently, things have changed: Jonas Nick and Tim Ruffing (from Blockstream Research), along with Yannick Seurin (from Ledger), published a paper that transformed the story of this cryptographic specter into a concrete, provable result. " DahLIAS " is the first formal, secure construction of a constant-volume (cross-input) fully aggregate signature scheme that works on Bitcoin's native curve!
There are many modifiers here, which we need to explain one by one:
- Full aggregation : Multiple signatures scattered across different inputs can be merged into one—resulting in a single 64-byte signature; the signature size always remains constant, regardless of the number of signers or inputs.
- Cross-input : Each signer can authorize different inputs, and all signatures will eventually be merged into a single signature.
Aside from the assumptions already relied upon by Bitcoin, DahLIAS doesn't add many new assumptions. In other words, using the mathematics already relied upon by Bitcoin, DahLIAS forms a new cryptographic primitive, unlocking entirely new signature types.
Let's talk about curves and signatures first.
Digital signatures are a means of proving that a user has authorized a transaction in the Bitcoin world. When you want to spend Bitcoin, your wallet software uses a private key to sign a message, and then the entire network (full nodes) uses the corresponding public key to verify that signature.
Bitcoin uses an elliptic curve algorithm, model " secp256k1, " which users use to generate public keys and signatures. It is fast, efficient, and well-tested. It supports signature schemes like " ECDSA " and " Schnorr "; the former is the original signature algorithm used by Bitcoin, while the latter was added in the 2021 "Taproot" upgrade and can be used in P2TR outputs; these are currently the only signature schemes recognized by Bitcoin's consensus rules.
Traditionally, the mathematical operations relied upon for full signature aggregation are not supported on Bitcoin's curves (secp256k1) and therefore seem unattainable. These features generally rely on other types of elliptic curves. For example, the "BLS (Boneh–Lynn–Shacham)" signature uses a special type of curve called "matching curves" to enable advanced operations such as merging multiple signatures (even signatures of different messages) into a single signature.
The problem is that BLS signatures don't work on secp256k1. While moving from ECDSA to Schnorr is a natural upgrade, as both rely on the same type of elliptic curve, adding BLS signatures would be a much larger leap, meaning a departure from Bitcoin's existing security model. While technically possible, it would introduce new cryptographic assumptions and significantly increase the protocol's complexity. Supporting a suitable curve for pairing, such as " BLS12-381 ," would be a major change for Bitcoin.
This is part of the reason why fully aggregated signatures have never been implemented on secp256k1.
Until now.
The principle of signature aggregation
Most Bitcoin users are familiar with multi-signature. In a multi-signature wallet, multiple people jointly authorize the spending of a single UTXO (or "coin"). Each person signs the same input data. This setup is useful, for example, for shared custodial wallets.
Aggregated signatures work differently. Instead of multiple people signing the same input (or money), each person authorizes a different input (UTXO) for a transaction. These individual signatures are then compressed into a single, compact piece of evidence. Using DahLIAS, this means that verifying a 64-byte signature on Bitcoin's secp256k1 curve is sufficient to verify all the inputs.
(Translator's note: To avoid misunderstanding, in the Bitcoin world, "aggregating signatures of multiple public keys for the same message into a single signature" is also considered aggregated signature, such as MuSig and MuSig2, which are aggregated signatures based on Schnorr; the situation the author is referring to here (aggregating signatures of multiple public keys for different messages into a single signature) is usually classified as "CISA (Cross-Input Signature Aggregation)".)
That is to say, originally, if a transaction had five different inputs from five different people, then the transaction would contain five different signatures. With aggregate signatures, all these signatures can be bound into one. Even if each signer uses different inputs and signs different parts of the transaction, it doesn't matter: the result is just one signature proving that the transaction has been properly authorized.
This is like compressing many licenses into a single file. The signature is compact, but still verifiable, proving that each signer authorized their own UTXO.
This can help realign incentives for privacy. By reducing signature overhead to a mere 64 bytes of evidence, DahLIAS lowers the overhead of merging inputs in CoinJoin transactions , making it financially wiser to choose privacy transactions than not.
Why did the "half-polymerization" scheme end?
Shortly after Schnorr signatures were introduced to Bitcoin, developers explored a " halving aggregation " scheme as a way to compress multiple signatures, but the result was not a fixed size. Each additional input increased the final proof size, so the transaction volume still increased with the number of participants. DahLIAS fixed this by implementing full aggregation between inputs and signers. Regardless of how many people participated or what they signed, all signatures are compressed into a single, fixed-size (64-byte) piece of evidence.
The real use of DahLIAS
The main benefit of using DahLIAS is that it reduces the size of complex transactions.
DahLIAS uses a two-round interactive signing process. This is similar to MuSig2 at the interactive level; however, it is not a multi-signature protocol because it does not require all participants to jointly sign the same message. Instead, it aggregates signatures for different messages.
DahLIAS verification is also faster than verifying each signature individually, up to twice as fast. Lower verification costs will allow more people to run full nodes, helping to protect Bitcoin's decentralization.
Importantly, DahLIAS possesses strong cryptographic guarantees. This scheme includes formal security proofs. Earlier "developer myth" methods lacked this, and some were even later proven insecure. Therefore, it was fortunate that they weren't adopted too early.
It's worth repeating: DahLIAS is not a multi-signature protocol . It cannot be functionally compared to MuSig2 or FROST, even though their cryptographic foundations are similar. Its purpose is elsewhere. It provides a new way to encode multiple independent licenses into a clear, verifiable package.
Future direction
You might be thinking: If DahLIAS is so powerful, why doesn't it have a BIP? Why not propose adding it to Bitcoin?
DahLIAS signatures differ from Schnorr and ECDSA signatures. Their verification algorithm is different; instead of using a public key, a message, and a signature for verification, it uses a set of public keys and a corresponding set of messages, plus a 64-byte piece of evidence.
This makes DahLIAS incompatible with Bitcoin's current consensus rules. Supporting it at the base layer would require a consensus change. The DahLIAS paper doesn't propose such a change, but what it does is equally important.
This paper demonstrates that it is possible to design a fully aggregated signature scheme on Bitcoin's native elliptic curve .
Even so, this is still a great improvement.
For DahLIAS to be integrated into Bitcoin, someone needs to write a BIP (Block Interface Protocol), possibly even using secp256k1lab . This means specifying the details of the scheme, considering its impact on consensus and implementation, and building community support. The paper merely lays the cryptographic foundation for such a transformation.
The true value of the DahLIAS paper lies in what it proves. Achieving full signature aggregation on secp256k1 is no longer just a concept. It's a reality, efficient and secure. For years, this idea remained merely a developer's tale. Now, it's written down, analyzed, and proven. All that remains is to bring it to Bitcoin if we wish.
(over)
