{"id":3496,"date":"2025-05-21T22:16:09","date_gmt":"2025-05-21T22:16:09","guid":{"rendered":"https:\/\/digkrypton.com\/index.php\/2025\/05\/21\/not-ecdsa-not-schnorr-meet-dahlias\/"},"modified":"2025-05-21T22:16:09","modified_gmt":"2025-05-21T22:16:09","slug":"not-ecdsa-not-schnorr-meet-dahlias","status":"publish","type":"post","link":"https:\/\/digkrypton.com\/index.php\/2025\/05\/21\/not-ecdsa-not-schnorr-meet-dahlias\/","title":{"rendered":"Not ECDSA. Not Schnorr. Meet DahLIAS."},"content":{"rendered":"

Bitcoin Magazine<\/a><\/p>\n

Not ECDSA. Not Schnorr. Meet DahLIAS.<\/a><\/p>\n

<\/div>\n

Aggregate signatures aren\u2019t new. They\u2019ve been around since the early 2000s. But building one that actually works in Bitcoin\u2019s security model, with Bitcoin\u2019s elliptic curve, has never been proven. Developers speculated it might be possible. They shared hand-wavy sketches and said, \u201cmaybe it\u2019d work like MuSig2<\/a>, but across transaction inputs.\u201d The idea lingered for years as developer folklore<\/em>, close, never provably confirmed.<\/p>\n

That changed recently, when Jonas Nick and Tim Ruffing of Blockstream Research, together with Yannick Seurin of Ledger, published a paper that turned this cryptographic ghost story into a concrete, provable result. DahLIAS<\/strong><\/a> is the first formal, secure construction of a full constant-size aggregate signature (CISA) scheme<\/strong> that works on Bitcoin\u2019s native curve!\u00a0<\/p>\n

But that\u2019s a lot of words, so let\u2019s break that down:<\/p>\n

Full aggregation<\/strong>: Multiple signatures across different inputs are combined into one \u2014 and the result is a 64 byte signature whose size stays constant, no matter how many signers or inputs.\u00a0<\/p>\n

Cross-input<\/strong>: Each signer can authorize different inputs, and all combine into one signature.<\/p>\n

It adds no significant new assumptions beyond those already relied on by Bitcoin. DahLIAS builds a new cryptographic primitive using the same math Bitcoin already relies on, unlocking an entirely new kind of signature.<\/p>\n

Let\u2019s Talk About Curves and Signatures<\/strong><\/h2>\n

Digital signatures are how Bitcoin proves that a user has authorized a transaction. When you go to spend bitcoin, your wallet uses a private key to sign a message, and the network verifies that signature using the matching public key.<\/p>\n

Bitcoin uses the secp256k1<\/strong> curve. It is fast, efficient, and has been battle-tested over time. It supports signature schemes like ECDSA<\/strong> (Bitcoin\u2019s original signature algorithm) and Schnorr<\/strong> (added through Taproot in 2021), which are currently the only signature schemes permitted by Bitcoin consensus.<\/p>\n

Traditionally, full signature aggregation relied on mathematical operations not supported by Bitcoin\u2019s curve, secp256k1, which made it seem out of reach. These features have typically relied on other types of elliptic curves. For example, BLS (Boneh\u2013Lynn\u2013Shacham) signatures use a special kind of curve called a pairing-friendly curve, which enables advanced operations like combining many signatures, even on different messages, into one.<\/p>\n

The problem is that BLS signatures do not work on secp256k1. While Schnorr was a natural upgrade from ECDSA, since both rely on the same kind of elliptic curve, adding BLS would be a much bigger leap and a departure from Bitcoin\u2019s existing security model. Though technically possible, it would introduce new cryptographic assumptions and add significant complexity to the protocol. Supporting a curve that is pairing-friendly, like BLS12-381<\/strong>, would be a major change for Bitcoin<\/em>.<\/p>\n

This is part of why full signature aggregation has never been done on secp256k1.<\/p>\n

Until now.<\/p>\n

What Aggregate Signatures Actually Do<\/strong><\/h2>\n

Most Bitcoin users are familiar with multisignatures. In a multisig<\/strong> wallet, multiple people jointly authorize the spending of a single UTXO or some specific \u201ccoin\u201d. Everyone signs the same input data. This setup is useful for things like shared custody wallets.<\/p>\n

Aggregate signatures<\/strong> work differently. Instead of multiple people signing the same input or coin, each signer authorizes a different UTXO in a transaction. These separate signatures are then compressed into one compact proof. With DahLIAS, that means a single 64-byte signature<\/strong> on Bitcoin\u2019s secp256k1 curve that verifies all inputs at once.<\/p>\n

That means if you have five inputs from five different people, the transaction needs five different signatures. With an aggregate signature, all of those can be bundled into one. Even if each signer is spending a different input and signing a different part of the transaction, the result is one signature that proves the entire transaction was properly authorized.<\/p>\n

It\u2019s like zipping a whole list of approvals into one file. The signature is compact, but still verifiably proves that each signer authorized their specific UTXO.<\/p>\n

Instead of verifying 10 separate signatures, you verify one.<\/p>\n

This helps realign incentives for privacy. By reducing the signature overhead to a single 64-byte proof, DahLIAS lowers the cost of combining inputs in CoinJoins, <\/strong>making it financially smarter to choose privacy than to go without it.<\/strong><\/p>\n

Why Half-Aggregation Got Close<\/strong><\/h2>\n

Shortly after Schnorr signatures were introduced on Bitcoin, developers explored half-aggregation<\/strong><\/a>, as a way to compress multiple signatures but they were not fixed size. Each input contributes to the size of the signature, so the transaction still grows with every participant. DahLIAS fixes this by enabling full-aggregation<\/strong> across inputs and signers. No matter how many people are involved or what they\u2019re signing, all their signatures compress into one constant-size, 64-byte proof.<\/p>\n

What DahLIAS Actually Unlocks<\/strong><\/h2>\n

The main benefit here is that DahLIAS are reducing the size of complex transactions.<\/p>\n

DahLIAS uses a two-round interactive signing process. It\u2019s similar to MuSig2 in that regard, but it isn\u2019t a multisignature protocol because it doesn\u2019t require all participants to co-sign the same message. Instead, it aggregates different signatures on different messages across the transaction.<\/p>\n

DahLIAS is also faster to verify than checking each signature individually, up to twice as fast in some cases. Lower verification costs make it easier for more people to run full nodes, which helps preserve Bitcoin\u2019s decentralization over time.<\/p>\n

Importantly, DahLIAS comes with strong cryptographic guarantees. The scheme includes formal security proofs. Earlier \u2018folklore\u2019 approaches to full signature aggregation lacked this, and some were even later shown to be insecure. Fortunately they weren\u2019t adopted prematurely.<\/p>\n

It\u2019s worth repeating: DahLIAS is not a multisig protocol.<\/strong> It isn\u2019t comparable to MuSig2 or FROST from a functional standpoint, even if it shares similar cryptographic building blocks. It serves a different purpose. It offers a new way to encode many independent approvals into one clean, verifiable package.<\/p>\n

Future Directions<\/strong><\/h2>\n

You might think: if DahLIAS is so powerful, why isn\u2019t it a BIP? Why not propose it for Bitcoin consensus?<\/p>\n

DahLIAS signatures don\u2019t look like Schnorr or ECDSA signatures. The verification algorithm is different. Instead of taking a single public key, message, and signature, a DahLIAS verifier takes lists<\/strong> of public keys and messages, and a single 64-byte proof.<\/p>\n

This makes DahLIAS incompatible with Bitcoin\u2019s current consensus rules. Supporting it at the base layer would require a consensus change. This paper doesn\u2019t propose that change, but it does something equally important.<\/p>\n

This paper shows that a full signature aggregation scheme for Bitcoin\u2019s native curve is possible.<\/strong><\/p>\n

That alone is a major step forward.<\/p>\n

To make DahLIAS part of Bitcoin, someone would need to write a Bitcoin Improvement Proposal (BIP), maybe even using secp256k1lab<\/a>. That means specifying the scheme in detail, considering its implications for consensus and implementation, and building community support. This paper lays the cryptographic foundation for that conversation.<\/p>\n

The real value of the DahLIAS paper is what it proves. Full signature aggregation on secp256k1 is not just a thought experiment. It\u2019s concrete. It\u2019s efficient. It\u2019s secure. For years, the idea lived in developer folklore. Now, it\u2019s written down, analyzed, and proven. All that\u2019s left is to bring it to Bitcoin\u2014if we want it.<\/p>\n

This is a guest post by Kiara Bickers. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.<\/em><\/p>\n\n

This post Not ECDSA. Not Schnorr. Meet DahLIAS.<\/a> first appeared on Bitcoin Magazine<\/a> and is written by Kiara Bickers<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Bitcoin Magazine Not ECDSA. Not Schnorr. Meet DahLIAS. Aggregate signatures aren\u2019t new. They\u2019ve been around since the early 2000s. But building one that actually works in Bitcoin\u2019s security model, with Bitcoin\u2019s elliptic curve, has never been proven. Developers speculated it might be possible. They shared hand-wavy sketches and said, \u201cmaybe it\u2019d work like MuSig2, but […]<\/p>\n","protected":false},"author":0,"featured_media":3497,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"tdm_status":"","tdm_grid_status":"","footnotes":""},"categories":[1],"tags":[],"class_list":{"0":"post-3496","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-bitcoin"},"acf":[],"_links":{"self":[{"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/posts\/3496","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/comments?post=3496"}],"version-history":[{"count":0,"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/posts\/3496\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/media\/3497"}],"wp:attachment":[{"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/media?parent=3496"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/categories?post=3496"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/digkrypton.com\/index.php\/wp-json\/wp\/v2\/tags?post=3496"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}