CISA Research

Cross-Input Signature Aggregation for Bitcoin


There are multiple paths that could theoretically be used to introduce CISA to Bitcoin. It has been pointed out here and here that a new Segwit version may be the safest option, but more research is welcome and needed before a proposal can be formalized.

Soft fork requirement and security considerations

Activation of CISA, no matter in which form, requires a soft fork since it adds a new verification algorithm. This has serious security implications. Bitcoin can only be as secure as the weakest of its verification algorithms and should spending with aggregate signatures turn out to be vulnerable, this would also put all funds that can be spent with Schnorr signatures at risk even if Schnorr signatures themselves remain secure.

A few proposals for Bitcoin consensus changes make use of signature aggregation. In the spirit of Taproot, which included multiple changes/BIPs that could have been deployed separately, it is interesting to keep an eye on these proposals and investigate if it may be interesting to integrate them into a wider proposal.


Proposes the possibility to delegate spending of an output to a different script, called a surrogate script. As these surrogate scripts can be chained, the signatures for each of the delegations can be aggregated to keep on-chain overhead minimal.

Read the mailing list post


Improvement of Graftroot, combining it with the idea of G’root.

Read the mailing list post