Cross-Input Signature Aggregation: How CISA Could Cut Bitcoin Transaction Costs
Cross-input signature aggregation (CISA) could reduce multi-input Bitcoin transaction sizes by 20-30%, but requires a soft fork.
Every Bitcoin transaction with multiple inputs carries a separate Schnorr signature for each one: 64 bytes per input, paid for entirely by the sender. Cross-input signature aggregation (CISA) proposes collapsing those individual signatures into fewer bytes, or in the strongest variant, a single 64-byte aggregate regardless of input count. The potential savings are significant: roughly 20–26% fewer bytes for typical transactions, with consolidation and CoinJoin transactions benefiting even more.
CISA has been discussed in Bitcoin research circles since the Taproot upgrade activated in 2021, but it was intentionally deferred to keep that soft fork manageable. Now, with three BIP drafts filed in mid-2026 and a peer-reviewed cryptographic scheme (DahLIAS) published at EUROCRYPT 2026, the proposal is moving from theory toward concrete specification. This article covers the mechanism, the two aggregation variants, the deployment path, and the economic implications for Bitcoin users.
Why Signature Aggregation Matters
Under BIP 340, each Schnorr signature is exactly 64 bytes (two 32-byte components: the nonce commitment R and the response scalar s). Thanks to the witness discount, each signature costs 16 virtual bytes of block weight. That cost is modest for a single-input transaction, but it scales linearly. A 10-input consolidation transaction carries 640 bytes of signature data. A 50-participant CoinJoin carries 3,200 bytes of signatures alone.
These are bytes that convey no unique information to verifiers beyond "each input is authorized." If a single proof could establish that all inputs are authorized simultaneously, the redundant data disappears. That is the core insight behind CISA: the linearity of Schnorr signatures makes this kind of aggregation mathematically possible.
Key distinction: CISA aggregates signatures across different inputs within a transaction, where each input has a different public key and signs a different message. This differs from key aggregation schemes like MuSig2, which combine multiple keys into a single key that co-signs one message.
How Schnorr Linearity Enables Aggregation
A BIP 340 Schnorr signature consists of a pair (R, s) where R is an elliptic curve point (the nonce commitment) and s is a scalar satisfying the equation s = k + e·x, with k being the secret nonce, e the challenge hash, and x the private key. The critical property is that the s-component is a simple linear equation over scalars. Given two signatures (R₁, s₁) and (R₂, s₂) from different signers on different messages, their s-components can be combined arithmetically:
s_agg = s₁ + s₂ (simplified)
This linearity does not exist in ECDSA, where the signature equation involves division in a finite field, making naive aggregation impossible. It is precisely why Schnorr signatures were adopted in BIP 340: aggregation was always part of the long-term roadmap, even though it was not included in the initial Taproot deployment.
The challenge: preventing rogue keys
Naive aggregation is insecure. An attacker could craft a signature that cancels out another signer's contribution, effectively forging authorization for inputs they do not control. Both CISA variants address this by incorporating random challenges (derived from all public keys and messages) that bind each signature to the full aggregation context, preventing cancellation attacks.
Half-Aggregation: The Non-Interactive Approach
Half-aggregation, specified in BIP 458 (filed June 28, 2026), combines the s-components of all signatures while preserving individual R values. The result is a half-aggregate signature of (n + 1) × 32 bytes for n inputs: all n nonce commitments (32 bytes each) plus one combined 32-byte scalar.
Size formula
| Input count | Standard signatures | Half-aggregate | Signature savings |
|---|---|---|---|
| 2 inputs | 128 bytes | 96 bytes | 25% |
| 5 inputs | 320 bytes | 192 bytes | 40% |
| 10 inputs | 640 bytes | 352 bytes | 45% |
| 50 inputs | 3,200 bytes | 1,632 bytes | 49% |
The savings approach 50% asymptotically because the R values are preserved. For the average historical Bitcoin transaction, half-aggregation yields approximately 20.6% byte savings and 7.6% weight savings, since each input still carries its outpoint reference (~36 vbytes), sequence number, and other non-signature data.
Non-interactive property
The defining advantage of half-aggregation is that it is non-interactive: anyone can aggregate existing valid signatures without cooperation from the original signers. A node, a miner, or even a relay could take a set of individually signed inputs and compress them into a half-aggregate after the fact. This opens the door to block-level aggregation, where all signatures within an entire block are half-aggregated by the block producer, though such an extension is not part of the current BIP.
Full-Aggregation: The DahLIAS Scheme
Full-aggregation, specified in BIP 459 (filed July 11, 2026), produces a constant-size 64-byte aggregate signature regardless of input count. Two inputs or two hundred: the aggregate is always 64 bytes.
BIP 459 implements the DahLIAS scheme (Discrete Logarithm-Based Interactive Aggregate Signatures), published in April 2025 by Jonas Nick and Tim Ruffing of Blockstream Research alongside Yannick Seurin of Ledger. The paper was peer-reviewed and published at EUROCRYPT 2026, making it the first interactive aggregate signature scheme proven secure for Bitcoin's secp256k1 curve.
Size formula
| Input count | Standard signatures | Full-aggregate | Signature savings |
|---|---|---|---|
| 2 inputs | 128 bytes | 64 bytes | 50% |
| 5 inputs | 320 bytes | 64 bytes | 80% |
| 10 inputs | 640 bytes | 64 bytes | 90% |
| 50 inputs | 3,200 bytes | 64 bytes | 98% |
Interactive requirement
The tradeoff is interactivity. Full-aggregation requires all signers to participate in a two-round signing protocol: they must exchange nonce commitments before producing the final aggregate. This is acceptable for CISA at the transaction level because constructing a transaction already requires signer cooperation. It does rule out block-level aggregation by miners, since miners cannot retroactively interact with every transaction signer.
Combining both approaches: Half-aggregation and full-aggregation are not mutually exclusive. A transaction could use full-aggregation internally, and a block producer could then half-aggregate the resulting per-transaction signatures across the entire block. The BIPs are designed to compose.
Half-Aggregation vs Full-Aggregation
The two variants occupy different points in the design space. The choice between them affects not only space savings but also protocol compatibility, verification performance, and deployment complexity.
| Property | Half-Aggregation (BIP 458) | Full-Aggregation (BIP 459) |
|---|---|---|
| Output size | 32n + 32 bytes | Constant 64 bytes |
| Interactivity | Non-interactive | Two-round interactive protocol |
| Byte savings (avg tx) | ~20.6% | ~26.1% |
| Weight savings (avg tx) | ~7.6% | ~9.6% |
| Block-wide aggregation | Possible (non-interactive) | Not practical |
| Adaptor signature compatibility | Incompatible | Compatible |
| Verification speed | Similar to BIP 340 batch verification | Up to 2x faster than half-aggregate |
| Security model | ROM + Algebraic Group Model | ROM + algebraic one-more DL assumption |
| Max signatures per aggregate | 65,535 | 65,535 |
For transaction-level CISA, full-aggregation is generally preferred because the interactivity requirement aligns with the existing signing workflow. Half-aggregation's non-interactive property becomes valuable for block-wide aggregation or Layer 2 protocols like Lightning gossip messages, where signatures are produced independently and aggregated later.
The Soft Fork Path
CISA requires a consensus change to Bitcoin. The most likely deployment mechanism is a new SegWit witness version (v2 or later) via soft fork. A draft consensus BIP was submitted on July 21, 2026, targeting Taproot key-path spends specifically.
Why a new witness version?
Deploying CISA under a new SegWit version rather than modifying Taproot (v1) directly serves two purposes. First, it preserves backward compatibility: existing Taproot transactions continue to work unchanged. Second, it allows Tapscript-path signatures to remain unaggregated, preserving compatibility with adaptor signatures used in protocols like atomic swaps, discreet log contracts, and certain Lightning channel constructions.
Current BIP landscape
The CISA proposal is structured across three complementary BIPs, all co-authored or authored by Fabian Jahr (Brink, HRF CISA Research Fellow), Jonas Nick, and Tim Ruffing (Blockstream Research):
- BIP 458: defines the half-aggregation cryptographic primitive (filed June 28, 2026)
- BIP 459: defines the full-aggregation primitive using DahLIAS (filed July 11, 2026)
- CISA consensus draft: specifies how aggregated signatures are validated in Bitcoin transactions (filed July 21, 2026)
This layered structure separates the cryptographic primitives from the consensus rules, allowing each component to be reviewed and tested independently. No activation timeline has been proposed.
Economic Impact on Consolidation Transactions
UTXO consolidation transactions are dominated by inputs: many small UTXOs merging into one output. These transactions see the largest absolute savings from CISA because signature data represents a higher fraction of the total transaction weight.
Consider a concrete example from Fabian Jahr's HRF research paper: a multi-input consolidation transaction that would cost 83,573 sats in fees without CISA could save 12,157 sats (a 12.7% fee reduction and 36.4% byte reduction for that particular transaction) with full-aggregation.
Lowering the dust threshold
Cheaper consolidation has a cascading effect. By reducing the cost to spend small UTXOs, CISA effectively lowers the dust threshold: the minimum UTXO value worth spending on-chain. UTXOs that are currently economically unspendable during high-fee periods could become viable to consolidate, improving UTXO set hygiene across the network.
Exchanges and payment processors that accumulate thousands of small UTXOs daily stand to benefit most. These entities already batch transactions and time consolidations for low-fee windows. CISA would reduce those costs further, improving their unit economics for every on-chain operation.
Privacy Implications: CoinJoin and PayJoin
CISA's most discussed secondary effect is its impact on Bitcoin privacy. Multi-input transactions are the backbone of collaborative privacy protocols like CoinJoin and PayJoin, where multiple participants combine their inputs into a single transaction to break the common-input-ownership heuristic.
Removing the privacy tax
Today, CoinJoin transactions cost more per participant than standard transactions because each participant adds at least one input (and its 64-byte signature). This creates a "privacy tax": doing the right thing for privacy costs more than sending a normal payment. CISA reduces this premium by compressing the per-participant signature overhead. With full-aggregation, the marginal signature cost of adding a participant to a CoinJoin approaches zero.
The economic argument is compelling: when privacy-enhancing transactions are cheaper, wallet developers face stronger incentives to integrate CoinJoin and PayJoin by default. The shift moves privacy from a deliberate, costly choice to a natural default, which is the only way privacy tools achieve meaningful adoption.
The counterargument: strengthening chain analysis
Full-aggregation has a subtle privacy downside. If a transaction uses a fully aggregated signature, it implies that all input signers cooperated during the signing protocol. For standard single-user transactions (where the same person controls all inputs), this reveals no new information. But it could strengthen the common-input-ownership heuristic for chain analysts: if aggregation becomes the default, the absence of aggregation in a multi-input transaction becomes a signal that the inputs may belong to different entities who could not or did not coordinate.
This tradeoff is acknowledged in the cisaresearch.org FAQ. The net effect depends on adoption patterns: if CoinJoin transactions also use CISA (which they would, to save fees), the heuristic becomes less reliable overall because both single-party and multi-party transactions use the same aggregation format.
Adaptor Signature Compatibility
One of the most discussed technical concerns is CISA's interaction with adaptor signatures, a cryptographic primitive used in atomic swaps, discreet log contracts, and PTLCs for Lightning.
Half-aggregation breaks adaptor signatures because the secret values embedded in adaptor-signed transactions become unrecoverable once the s-components are combined. Full-aggregation, by contrast, preserves adaptor signature functionality because signers are already interacting during the signing protocol and can handle the adaptor reveal independently.
The proposed solution is architectural: under a new SegWit version, Tapscript-path signatures would remain unaggregated. Protocols requiring adaptor signatures would use script-path spends instead of key-path spends. The tradeoff is that script-path spends are larger and more expensive than key-path spends, and they "stick out" from normal aggregated transactions, creating a privacy fingerprint for adaptor-based protocols.
Security Considerations
CISA introduces a new signature verification algorithm to Bitcoin's consensus rules. As cisaresearch.org notes: "Bitcoin can only be as secure as the weakest of its verification algorithms." Any vulnerability in the aggregate signature scheme could endanger all funds using the new witness version.
The DahLIAS scheme has undergone peer review and was published at a top-tier cryptography conference (EUROCRYPT 2026). Half-aggregation builds on the algebraic group model with a Random Oracle assumption. Both schemes have formal security proofs, but the gap between a proof and a deployed implementation in a system securing hundreds of billions of dollars is nontrivial. The BIP review process, reference implementations, and extensive test vectors are designed to close that gap.
CISA in Context: On-Chain vs Off-Chain Scaling
CISA is fundamentally an on-chain optimization. It makes base-layer transactions smaller and cheaper, which benefits every user who touches Bitcoin L1. But it does not change the throughput ceiling: Bitcoin still produces blocks at roughly the same rate with the same weight limit.
Off-chain protocols take a different approach entirely. Spark, for example, uses statechain transfers that move Bitcoin ownership without broadcasting any on-chain transaction. Where CISA reduces the cost of on-chain signatures from 64 bytes per input to potentially 64 bytes total, Spark bypasses the signature cost entirely: transfers happen off-chain via FROST threshold key rotation, with on-chain transactions only needed for deposits and exits.
These approaches are complementary rather than competing. CISA makes on-chain operations cheaper for users who need them (consolidation, large payments, settlement). Off-chain protocols like Spark and Lightning handle the high-frequency, low-value transfers that would be impractical on-chain regardless of CISA's savings. A user consolidating UTXOs on L1 before depositing into Spark would benefit from both: cheaper consolidation via CISA, then free transfers within Spark.
Timeline and Open Questions
With BIP 458, BIP 459, and the CISA consensus draft all filed in mid-2026, the proposal is entering its most active phase. Several open questions remain:
- Which SegWit witness version will CISA use, and will it share that version with other proposed consensus changes like OP_CAT or CTV?
- Will block-wide half-aggregation be pursued as a follow-on proposal, or left for a future soft fork?
- How will wallet developers handle the transition? New CISA-enabled addresses would coexist with Taproot (v1) addresses indefinitely.
- What is the interaction between CISA and other proposed changes to Bitcoin's fee market, such as cluster mempool?
No activation mechanism or timeline has been proposed. Given Bitcoin's conservative approach to consensus changes, the review period for CISA will likely span years rather than months, with extensive testing on signet and testnet before any activation attempt.
What CISA Means for Developers and Users
For developers building Bitcoin applications today, CISA is a future optimization to design for, not a feature to rely on. Wallet developers should continue using P2TR (Taproot) outputs and efficient coin selection to minimize input counts. When CISA activates, these wallets will benefit automatically through fee reductions on multi-input transactions.
For users, the impact depends on usage patterns. Those who frequently consolidate UTXOs, use CoinJoin, or make payments from multiple inputs will see the most significant fee reductions. Single-input transactions gain nothing from CISA, since there is nothing to aggregate.
For builders exploring Bitcoin's scaling landscape, the Spark SDK documentation provides a complementary path: off-chain transfers that eliminate on-chain signature costs entirely. Understanding both on-chain optimizations like CISA and off-chain protocols is essential for choosing the right architecture for each use case. For a broader view of Bitcoin scaling approaches, see our Bitcoin Layer 2 comparison.
This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.