<p>Pieter Wuille answered this on <a href="https://twitter.com/pwuille/status/1318238586592849920?s=20" rel="nofollow noreferrer">Twitter</a>.</p>
<p>The most important complication of cross input aggregation is explained in this Bitcoin dev mailing list <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015838.html" rel="nofollow noreferrer">post</a> by AJ Towns.</p>
<blockquote>
<p>TL;DR: if softforks change which signatures are checked, they mustn't
change what is aggregated together. This is especially complicated when they interact with BIP341's OP_SUCCESSx upgrade mechanism, which could easily let future softforks change script semantics entirely. There is nothing fundamentally hard here - it's just engineering complexity to make sure everything works well together.</p>
</blockquote>
<p>Pieter added at a London BitDevs <a href="https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-07-21-socratic-seminar-bip-taproot/" rel="nofollow noreferrer">Socratic Seminar</a> on BIP-Taproot:</p>
<blockquote>
<p>Graftroot and cross input aggregation are such deeply conceptual changes. You can’t permit building them later. It is such a structural change to how scripts work. These things are not something that can be just added later on top of Taproot. You need a successor. Cross input aggregation, the concept of script verification is no longer a per input thing but it is a per transaction thing. You can’t do it with optimal efficiency, I guess you can invent things. The type of extensibility that is built in is new opcodes, new types of public keys, new sighash types, all these things are made fairly easy and come with almost no downsides compared to not doing them immediately. Real structural changes to script execution, they need something else.</p>
</blockquote>
<p>edit (September 2023): The latest state of research on cross input signature aggregation (CISA) is summarized <a href="https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/README.md" rel="nofollow noreferrer">here</a>.</p>

CC BY-SA 4.0
2021-05-30T16:13:11.943Z
"These things are not something that can be just added later on top of Taproot." Isn't that exactly what will need to happen though?
nilskp
CC BY-SA 4.0
2021-05-31T17:19:34.117Z
@nilskp: There is a difference between building on top of Taproot (e.g. a new leaf version) and not leveraging Taproot. Pieter's point above is that cross input signature aggregation can't leverage Taproot and has to be built from scratch.
Michael Folkson
CC BY-SA 4.0
2021-10-28T11:00:31.197Z
Thanks @Murch, you're right. I'll delete that last edit.
Michael Folkson
CC BY-SA 4.0
2020-11-26T22:07:07.093Z
2023-09-11T10:59:24.370Z
2023-09-11T10:59:24.370Z
Michael Folkson
<p>What makes cross input signature aggregation complicated to implement? Other than for design space reasons why didn't it make it into BIP-Taproot? (Key aggregation within one input can be achieved with MuSig, MuSig2 etc but signatures cannot be aggregated across different inputs with BIP-Taproot.)</p>
<p>This questions was asked by Thorkil Vaerge on <a href="https://twitter.com/ThorkilVaerge/status/1318211576407666688?s=20" rel="nofollow noreferrer">Twitter</a>.</p>

<taproot><schnorr-signatures><cross-input-signature-aggregation>
What makes cross input signature aggregation complicated to implement?
Michael Folkson
# What makes cross input signature aggregation complicated to implement?

(Asked by: username_0 on 2020-11-26)

What makes cross input signature aggregation complicated to implement? Other than for design space reasons why didn't it make it into BIP-Taproot? (Key aggregation within one input can be achieved with MuSig, MuSig2 etc but signatures cannot be aggregated across different inputs with BIP-Taproot.)

This questions was asked by Thorkil Vaerge on [Twitter](https://twitter.com/ThorkilVaerge/status/1318211576407666688?s=20).

**Tags:** taproot, schnorr-signatures, cross-input-signature-aggregation


---

## 1 answers

### Answer by username_0 on 2020-11-26. Score: 5 | Accepted answer

Pieter Wuille answered this on [Twitter](https://twitter.com/pwuille/status/1318238586592849920?s=20).

The most important complication of cross input aggregation is explained in this Bitcoin dev mailing list [post](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015838.html) by AJ Towns.

> TL;DR: if softforks change which signatures are checked, they mustn't
> change what is aggregated together. This is especially complicated when they interact with BIP341's OP\_SUCCESSx upgrade mechanism, which could easily let future softforks change script semantics entirely. There is nothing fundamentally hard here - it's just engineering complexity to make sure everything works well together.

Pieter added at a London BitDevs [Socratic Seminar](https://diyhpl.us/wiki/transcripts/london-bitcoin-devs/2020-07-21-socratic-seminar-bip-taproot/) on BIP-Taproot:

> Graftroot and cross input aggregation are such deeply conceptual changes. You can’t permit building them later. It is such a structural change to how scripts work. These things are not something that can be just added later on top of Taproot. You need a successor. Cross input aggregation, the concept of script verification is no longer a per input thing but it is a per transaction thing. You can’t do it with optimal efficiency, I guess you can invent things. The type of extensibility that is built in is new opcodes, new types of public keys, new sighash types, all these things are made fairly easy and come with almost no downsides compared to not doing them immediately. Real structural changes to script execution, they need something else.

edit (September 2023): The latest state of research on cross input signature aggregation (CISA) is summarized [here](https://github.com/BlockstreamResearch/cross-input-aggregation/blob/master/README.md).

> **Comments:**
> **username_1**: "These things are not something that can be just added later on top of Taproot." Isn't that exactly what will need to happen though?  
> **username_0**: @username_1: There is a difference between building on top of Taproot (e.g. a new leaf version) and not leveraging Taproot. Pieter's point above is that cross input signature aggregation can't leverage Taproot and has to be built from scratch.  
> **username_0**: Thanks @Murch, you're right. I'll delete that last edit.  

---

