Cross-Input Signature Aggregation (CISA)

Cross-Input Signature Aggregation (CISA) is a proposed Bitcoin protocol upgrade that would let a transaction combine the separate signatures from all of its inputs into a single aggregate signature covering the whole transaction. Today each input carries its own 64-byte Schnorr signature; CISA collapses that redundancy, reducing transaction weight and therefore the fees a multi-input spend incurs. It is a research direction rather than a deployed feature, and any honest description has to keep that status front and centre.

Half-aggregation versus full aggregation

Two flavors are studied. Full aggregation would interactively merge all input signatures into one 64-byte signature, but it requires the signers to coordinate during signing, which complicates hardware wallets and multiparty setups. Half-aggregation is non-interactive: any third party can compress a set of BIP340 signatures into a combined signature roughly half the size of the originals, without involving the signers at all. The half-aggregation security proof reduces to the security of Schnorr signatures themselves, giving it a solid cryptographic footing rather than resting on new and untested assumptions.

Realistic savings

The benefit is meaningful but bounded, and it is worth being honest about that. Signatures are only part of an input's data. Even with aggregation, each input still carries its 36-byte outpoint and other fields, so CISA offers a modest per-transaction reduction that grows with input count — most valuable for consolidations, CoinJoins, and batched payments where many inputs are spent at once. A single-input payment saves nothing at all. The idea traces to block-wide aggregation discussions from 2017 and remains an active research track, so a wallet claiming to use it today would be premature.

The incentive question

CISA also nudges on-chain behaviour. Because aggregation makes many-input transactions relatively cheaper, it slightly rewards spending lots of small UTXOs together, which is the opposite of the current incentive that penalizes it. Some researchers see this as a feature that would encourage healthier UTXO management; others worry about second-order effects on how wallets choose coins. That debate is part of why CISA has been studied carefully rather than rushed.

Why it matters for sovereignty

Beyond fees, aggregation has a subtler upside for privacy tools. CoinJoins and other collaborative transactions gather many inputs from many parties; shrinking the signature overhead makes those privacy-preserving constructions cheaper and therefore more accessible. Anything that lowers the cost of consolidating UTXOs or coordinating a multiparty spend nudges the incentives toward better on-chain hygiene, which serves self-custodial users directly.

Because CISA changes how a fundamental part of every transaction is validated, it is the kind of proposal that moves slowly and deliberately through Bitcoin's review process, and rightly so. Any change to signature handling touches consensus — the set of rules every node must agree on exactly — so it demands extraordinary scrutiny before it could ship as a soft fork. Researchers must weigh not just the raw byte savings but the complexity added to wallets, the interaction with existing script types, and whether the incentive shifts it introduces are actually desirable. None of that happens quickly, and treating CISA as imminent would misread how conservatively the protocol evolves.

For a self-custodial user, the honest bottom line today is that CISA is a promising idea to understand rather than a tool to use. Its eventual value, if it is adopted, would be quietly structural: cheaper consolidations and cheaper collaborative privacy transactions, nudging the whole network toward tidier UTXO management. Following its progress is a good way to stay literate about where Bitcoin's efficiency and privacy frontiers are heading, without mistaking active research for a shipped feature.

CISA builds on the Schnorr signature scheme that Schnorr signatures define, operates on the x-only public keys Taproot introduced, and shares the batch-friendly linearity that already powers Schnorr batch verification.