The evolution of Bitcoin is a story of relentless, meticulous optimization. Since the genesis block, developers have wrestled with a fundamental law of blockchain physics : block space is strictly limited, and cryptographic security is incredibly data-heavy. Every byte saved is a victory for scalability, decentralization, and the economic viability of the network.

Recently, Fabian Jahr posted to the Bitcoin-Dev mailing list, unveiling a draft Bitcoin Improvement Proposal (BIP) that represents the next major frontier in this optimization journey. Now tracked as BIP459, this draft introduces a standard for the full aggregation of BIP340 Schnorr signatures using the DahLIAS aggregate signature scheme.

At its core, this proposal describes cryptographic alchemy : a process to take an unlimited number of individual signatures within a transaction and compress them into a single, unified 64-byte signature.

To understand why this is a monumental leap forward—and why it requires a fascinating two-round interactive protocol orchestrated by an untrusted coordinator—we need to dive deep into the mechanics of Bitcoin cryptography, the historical context of block space, the math behind the DahLIAS scheme, and the holy grail of Bitcoin scaling : Cross-Input Signature Aggregation (CISA).

The Relentless Pursuit of Block Space Efficiency

To fully appreciate the weight of BIP459, we must first look back at the historical bottlenecks of Bitcoin transactions.

A standard Bitcoin transaction is essentially a ledger entry that consumes existing unspent transaction outputs (UTXOs) as “inputs” and creates new UTXOs as “outputs.” To prove that you have the right to spend an input, you must provide a digital signature proving you hold the private key associated with that specific UTXO.

For the first decade of Bitcoin’s existence, the network relied exclusively on the Elliptic Curve Digital Signature Algorithm (ECDSA). While highly secure, ECDSA has a critical limitation : it is mathematically rigid. Every single input in a transaction requires its own distinct ECDSA signature, which typically takes up 71 to 73 bytes of data.

If you wanted to consolidate 100 small UTXOs into a single address, your transaction would need to include 100 separate ECDSA signatures. That is over 7,000 bytes of signature data alone—data that serves no purpose other than proving authorization, yet takes up valuable space in a block, driving up the transaction fees you must pay.

The SegWit and Taproot Revolutions

The community tackled this bloat in stages. In 2017, Segregated Witness (SegWit) separated the signature data (the “witness”) from the transaction data, applying a discount to how witness data is priced in terms of block weight. This made complex, signature-heavy transactions cheaper, but it didn’t reduce the actual byte count being stored on nodes.

Then came the Taproot upgrade in 2021, arguably the most significant cryptographic upgrade in Bitcoin’s history. Taproot introduced BIP340, integrating Schnorr signatures into the Bitcoin protocol.

Unlike ECDSA, Schnorr signatures are mathematically elegant. They are slightly smaller (a strict 64 bytes), but their true superpower is linearity. Because the mathematics of Schnorr signatures involves simple linear equations, you can perform arithmetic on them. You can add two private keys together, add their public keys together, and generate a signature that is mathematically valid for the combined public key.

This linearity enabled key aggregation (via protocols like MuSig2). With key aggregation, a 5-of-5 multisig wallet no longer needs to publish five separate signatures on the blockchain. Instead, the participants combine their keys off-chain and broadcast a single 64-byte signature that looks identical to a standard single-signature transaction.

The Lingering Problem : Independent Inputs

However, while MuSig2 solved the problem of aggregating signatures within a single input (multisig), it did nothing for transactions with multiple independent inputs.

If you and I decide to participate in a CoinJoin—a privacy technique where multiple users combine their inputs into one massive transaction to obscure the trail of funds—we still each have to provide independent signatures for our respective inputs. If a transaction has 50 inputs, it still requires 50 distinct 64-byte Schnorr signatures, totaling 3,200 bytes.

This is the exact problem that Fabian Jahr’s BIP459 seeks to solve. It moves us from key aggregation (combining signers for one lock) to full signature aggregation (combining all locks and keys across an entire transaction into a single master signature).