There have been so many dramatic things happening in Bitcoin lately that I completely missed this BIP draft for cross-input signature aggregation (CISA).

Bitcoiners have been talking about CISA for a while now (here is an explainer #923407 and a paper about it #920670 and a recent talk by fjahr #1544856 and a talk by Tim Ruffing #1518433) and it is interesting to see the proposals getting into a more finished form.

The tl;dr for cross-input signature aggregation is that you could have a transaction with inputs from many different keys (implying potentially many different owners) but onchain it would look like a single taproot signature for a single private key.

As fjahr points out in the BIP draft, CISA may provide:

• '''Lower fees and smaller transactions''': Signature data shrinks with the number of aggregated inputs, reducing transaction weight and fees and freeing up block space
• '''Reduced cost of privacy''': Aggregation reduces the signature cost of any batched transaction, and collaborative transactions such as CoinJoin and PayJoin benefit the most per participant because they batch the inputs of many users
• '''Flexible usage''': Two aggregation schemes serve different use cases and individual inputs can opt out
• '''Protocol compatibility''': The explicit opt-out protects protocols that depend on a specific signature appearing on chain

This BIP draft doesn't propose the actual aggregation scheme ("The aggregation schemes themselves are specified in BIP458 half-aggregation and BIP459 full-aggregation").

And it does require a soft fork.

fjahr also suggests some use cases:

• '''CoinJoin/PayJoin transactions''': With CISA, the per-participant cost of CoinJoin and PayJoin transactions decreases as the number of participants increases, making privacy-enhancing usage cheaper
• '''Consolidation and batching''': Businesses and users combining many small UTXOs into a single output or multiple payment outputs benefit from reduced transaction costs
• '''Lightning channel opens and splices''': Dual funding and splicing combine inputs from both peers in a collaborative transaction, and the existing interactive negotiation between the peers can accommodate the signing rounds of full-aggregation

I'm curious what some of the objections to this are. The main downside I saw on the mailing list was that this proposal adds validation complexity (I read this as fancy complicated math that nodes would need to be ready to accomodate). It may also suffer some from a problem that also plagues the covenant conversation: lots of options, and no clear way to decide which set of trade-offs should be adopted.

Anyhow, this is definitely one to watch!