Cross-Input Signature Aggregation (CISA)

What Is Cross-Input Signature Aggregation?

Cross-input signature aggregation (CISA) is a proposed upgrade to Bitcoin that would allow multiple inputs within a single transaction to share one aggregated signature rather than requiring a separate signature for each input. Today, every input in a Bitcoin transaction must include its own digital signature to prove authorization, which adds significant weight to transactions that spend many UTXOs. CISA would compress these individual signatures into a single proof that covers the entire transaction, saving block space and reducing fees for users.

The proposal builds on BIP 340 Schnorr signatures, which were activated as part of the Taproot soft fork in November 2021. Schnorr's linearity property makes signature aggregation mathematically possible: unlike ECDSA (the previous signature scheme), Schnorr signatures can be added together to produce a valid combined signature. CISA takes this property and applies it across all inputs in a transaction.

How It Works

In a standard Bitcoin transaction today, each input carries its own 64-byte Schnorr signature (or 72-byte ECDSA signature for older address types). A transaction spending 10 inputs therefore includes 10 separate signatures, consuming at least 640 bytes of witness data. With CISA, those 10 signatures would be combined into a smaller aggregated proof.

Two approaches to aggregation have been proposed, each with different tradeoffs:

Half Aggregation

Half aggregation (described in BIP 458) is a non-interactive process. It compresses a collection of Schnorr signatures into a single aggregate signature whose size is approximately half the combined size of the originals. For a transaction with n inputs, the resulting half-aggregate signature is roughly 32 + 32n bytes instead of 64n bytes.

The key advantage of half aggregation is that it requires no interaction between signers. Anyone, including the broadcasting node or even a miner, can aggregate the signatures after they have been individually produced. This makes it compatible with existing wallet workflows where multiple independent parties contribute inputs to a transaction without needing to coordinate a signing protocol.

For an average Bitcoin transaction, half aggregation saves approximately 20.6% in byte size and 7.6% in weight units.

Full Aggregation

Full aggregation (described in BIP 459) produces a single 64-byte signature regardless of how many inputs the transaction has. Whether a transaction spends 2 inputs or 200, the aggregated signature remains the same size as a single BIP 340 Schnorr signature.

This uses the DahLIAS (Discrete Logarithm-Based Interactive Aggregate Signatures) scheme, proposed in April 2025 by Jonas Nick, Tim Ruffing, and Yannick Seurin. As the name suggests, full aggregation is interactive: all signers must participate in a multi-round signing protocol to produce the aggregate signature. This makes it more complex to implement but delivers greater space savings.

For an average transaction, full aggregation saves approximately 26.1% in byte size and 9.6% in weight units.

Comparison

Why It Matters

CISA's significance extends beyond raw fee savings. By making multi-input transactions cheaper, it shifts the economic calculus around privacy and UTXO management in Bitcoin.

Fee Reduction

Every Bitcoin transaction competes for limited block space. Signatures are the largest component of most transactions, so compressing them directly reduces the fee rate users must pay. Transactions with many inputs, such as UTXO consolidation operations or exchange withdrawals using batching, would see the greatest benefit.

Privacy Incentives

Today, CoinJoin transactions cost more than regular transactions because they combine inputs from multiple participants, each adding a signature. This creates a perverse incentive: privacy costs extra. CISA would flip this dynamic. With signature aggregation, the per-participant cost of a CoinJoin could become cheaper than each participant creating a separate transaction.

Estimates show that a WabiSabi-style CoinJoin would save approximately 6.35% in fees with half aggregation and 12.7% with full aggregation. While these percentages may seem modest, the important shift is directional: privacy becomes the cheaper option rather than the more expensive one.

PayJoin transactions would also benefit. PayJoin already looks like a normal two-input transaction on-chain, and CISA would make it even cheaper, further incentivizing its adoption for everyday payments.

Block Space Efficiency

From a network perspective, CISA increases the effective capacity of each block. Smaller transactions mean more transactions fit per block, improving throughput without changing the block size limit. This is conceptually similar to how SegWit increased effective block capacity through the witness discount.

Use Cases

• UTXO consolidation: wallets managing many small UTXOs could aggregate all input signatures, dramatically reducing consolidation costs during low-fee periods
• CoinJoin and PayJoin: privacy-enhancing protocols with many participants benefit from reduced per-input signature overhead, making privacy cheaper than individual spending
• Exchange operations: exchanges and payment processors that routinely create transactions with dozens of inputs would see meaningful fee reductions
• Layer 2 settlement: protocols like Lightning channels and statechains that batch on-chain settlements could reduce their footprint through aggregated signatures
• Coin selection: wallets could afford to include more inputs without the fee penalty, simplifying UTXO management

Deployment Path

CISA requires a soft fork because the aggregated signature verification algorithm differs from standard BIP 340 Schnorr verification. Nodes that have not upgraded would be unable to validate aggregated signatures using existing rules, so a new consensus rule must be introduced.

Several deployment approaches have been discussed:

• A new SegWit version (beyond v1/Taproot) that defines aggregated signature validation rules
• Redefining an OP_SUCCESS opcode within Tapscript to introduce a new opcode like OP_CHECKAGGSIG

As of 2026, CISA remains in the research and specification phase. BIP drafts (458 and 459) exist for the underlying aggregation schemes, and researcher Fabian Jahr is leading a proof-of-concept implementation with PayJoin integration, supported by a Human Rights Foundation fellowship. The cryptographic building blocks, including the DahLIAS scheme for full aggregation, were published in 2025. However, no formal soft fork activation proposal has been put forward, and significant review of both the cryptographic primitives and consensus changes is still needed.

Risks and Considerations

Soft Fork Complexity

Any Bitcoin soft fork requires broad community consensus and extensive review. CISA introduces novel cryptographic verification logic into the consensus layer, which must be rigorously audited. The Taproot upgrade took years from initial proposal to activation, and CISA would likely follow a similar timeline.

Interaction Requirements for Full Aggregation

Full aggregation via DahLIAS requires all signers to participate in an interactive protocol. For single-signer transactions this is straightforward, but for multi-party protocols like CoinJoin, coordination becomes more complex. Half aggregation avoids this issue at the cost of smaller space savings.

Verification Performance

While batch verification of individual Schnorr signatures is well-understood, verifying aggregated signatures introduces different computational tradeoffs. Full nodes must be able to verify these efficiently to avoid slowing down block propagation and initial block download.

Regulatory Considerations

Because CISA incentivizes CoinJoin and other privacy-enhancing techniques through lower fees, it may draw scrutiny from regulators focused on chain analysis and transaction surveillance. This tension between privacy and regulatory compliance is inherent in the proposal's design goals.

Incremental vs. Bundled Deployment

There is ongoing discussion about whether CISA should be deployed as a standalone soft fork or bundled with other proposed upgrades. Bundling reduces the number of soft forks needed but increases the scope of review and the risk of political gridlock. A standalone deployment keeps the scope narrow but uses up a "soft fork slot" for a single optimization.

For a deeper look at how Schnorr signatures enable these aggregation techniques, see the research article on Taproot and Schnorr signatures. To understand the broader landscape of Bitcoin scaling proposals that CISA fits into, see Bitcoin's second-layer scaling landscape.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.