BIP460: CISA for Taproot Key Path Spends

[fjahr]

This is a BIP draft for transaction-wide cross-input signature aggregation (CISA). It introduces witness version 2, which enables Taproot-style key path spending where inputs can aggregate their signatures within a transaction. Each input chooses between half-aggregation, full-aggregation, or an explicit opt-out via a marker byte in its witness and the signature message commits to that choice. The aggregation schemes themselves are specified in BIP458 half-aggregation and BIP459 full-aggregation.

Compared to the version shared on the mailing list recently, this version incorporates feedback from vostrnad, most notably a rewritten rationale for excluding script path aggregation, describing the conflict with the OP_SUCCESS upgrade mechanism.

The test vectors are generated with Python code that builds on the reference implementations of BIP458 and BIP459, and the latest master of secp256k1lab is vendored with the BIP, same as it was done for BIP458/459.

Note to the BIP editors: I am aware that SegWit v2 here collides with BIP360. I am curious what you have to say about this, and I am happy to make a change here if you request it, but I couldn't find any rules assigning witness numbers in BIPs or anything that seemed close enough. Since witness versions are a scarce resource and not assigning them sequential would be kind of confusing, it seems whatever soft fork goes in next that requires a new witness version should get the next one available. Since both this one and BIP360 aren't close to activation, I am happy with whatever you decide to write into the specs in the meantime. Maybe we'll want to move to a more generic language for the version instead of prescribing it explicitly until activation comes close. On the other hand, maybe making it explicit and avoiding collisions makes sense for tests on Bitcoin Inquisition etc. Either way, it can't be avoided that there is a chance a "final" BIP might need a change in this regard at some point when it actually gets activated.

[fjahr]

This completes the CISA BIP triplet with half-agg (458) and full-agg (459) and should get BIP number 460 but I will wait for the editor confirmation again :)

[vostrnad]

Second pass of review for things I didn't notice the first time around, especially the opportunity to structure the specification around differences from SegWit v1 instead of reiterating many of its rules. The rationale for leaving out script path inputs reads great now.

[vostrnad]

It seems a bit inconsistent to have sections named Rationale (which describes rationale inline) and Footnotes (which describes rationale as footnotes). As an example, BIP-341 only has a Rationale section where all points are footnotes, and that way they can be referenced inline from places where the rationale needs explaining.

[fjahr]

I left this as is. It is consistent with, for example, BIP340 and BIP458 (where I didn't come up with the initial structure). Both mix prose rationale and a separate footnotes section. I think such a split can help with readability by keeping the parts that are deeper in the weeds in the footnotes.

[murchandamus]

I am aware that SegWit v2 here collides with BIP360.

I would also expect that whatever gets deployed first would get to use the next version and other proposals would shift. I guess you could write “version 2 (or the next unencumbered version available when this proposal is deployed)” or similar to be abundantly clear. At least one of the authors of BIP 360 was keen on using version 3 anyway, because he wanted quantum-resistant addresses to start with bc1r.

[fjahr]

Addressed inline comments from @vostrnad , thanks again for the extensive review!

I also added a bit to the rationale section in response to waxwing's comment here: https://groups.google.com/g/bitcoindev/c/1XH6sBLWZuA/m/-zRSmrFZGQAJ See my response on the mailing list for a bit more detail. As mentioned, there are, well, I am still open to consider adding this if reviewers can envision possible use cases or are just generally of the opinion we should offer as much flexibility as possible.

Also added the assigned number and made changes in response the recent renaming of BIP459.

I guess you could write “version 2 (or the next unencumbered version available when this proposal is deployed)” or similar to be abundantly clear.

I have something like this in the deployment section already, so I didn't make any further change in this regard.

[fjahr]

I have been working on a bigger revision of this proposal that I would like to ask if anyone sees downsides that I have missed before actually pushing it here. This new version would be making opted-out inputs plain BIP 341 key path spends. Draft version of the spec changes: fjahr/bips@cisa...cisa-plain-optout

A bit more detail: the opt-out marker 0xbb would be removed. Opted-out inputs carry a bare 64 or 65-byte BIP 341 signature over the unchanged BIP 341 message. The aggregation markers 0xbc/0xbd move from the first byte of the witness element to the last, the position of the sighash byte. Marker values are disjoint from valid sighash values, so this resolves the 65-byte ambiguity that the opt-out marker existed to resolve. Aggregated inputs are otherwise unchanged and their messages still commit to the mode, so aggregation remains consensual.

The motivation comes from the adoption discussion in the PQC output type thread: https://delvingbitcoin.org/t/pqc-output-type-discussion/2749/6. My perspective has changed because if external factors like PQ migration drive part of the adoption of the output type, opted-out spends may be less of an exception than I thought. With this change a wallet that never aggregates spends witness v2 outputs with its existing Taproot signing logic, no new sighash code path, no new witness logic. A CISA-enabled witness v2 becomes a strict superset of a plain "P2TRv2" with BIP 341 semantics.

@vostrnad suggested the key elements of this in earlier review, the sighash byte trailing the signature and opting out by omitting the marker. I rejected both at the time because I saw opting out as a rare case that could afford an explicit byte. Due to the external motivation for adoption of the output type I now see this differently. I also didn't put these two suggestions together which caused me to expect this change to be more complicated than it ended up actually being.

Pros of the new version:

• Opted-out spends are byte-identical to BIP 341 key path spends: same witness, same message, same signing code, making initial adoption easier even if CISA use is not interesting/too complex for a wallet/client implementation at the start.
• One byte saved per opted-out input.

Cons:

• Cross-version replay protection between v1 and v2 now rests on the scriptPubKey commitment in SigMsg instead of a separate sighash epoch.
• The marker sits at the end of the element, unlike other tags in the taproot family, and its values cannot become sighash types in a future witness version that inherits this grammar.

By now I believe that this is an improvement even if there is no combination with a PQ P2TRv2 proposal so I plan to update the pull shortly if I didn't overlook any serious issues. Feedback very welcome.

[conduition]

Hey @fjahr, reviewing the spec changes, here's a few observations:

• '''Marker''': Last byte (0xbc or 0xbd)

Nit: It's unusual to document the last element of an object's encoding first.

Opted-out spends are byte-identical to BIP 341 key path spends, so wallets that do not aggregate can adopt the new output type without new signing logic.

I think there would still be a difference w/r/t the witness program version, and perhaps some implementations naively assume the witness version during message hashing. So there will be some change needed during signing (otherwise replay can occur), but still changing a single byte is pretty minimal. Perhaps that one byte is still worth mentioning?

Opted-out inputs still need protection from non-consensual aggregation.

Crazy idea, but could you flip this logic on its head, and swap the signature message functions of the "opted out" and "half-agg" signatures? Then the default 'lazy path' (i.e. BIP341-style key spend with a new witness version) would be half-aggregatable, while the explicit opt-out signature would require manual changes by wallet devs.

Then if we allow half-aggregation by third parties, users who upgrade to CISA addresses would automatically gain the benefits of half-aggregation without doing any work aside from changing the witness version, since half-agg will presumably be done automatically for them by someone in the mempool, or by miners themselves (they have incentive to).

This has a security drawback though, for users who depend on adaptor signatures. They'd need to update their systems, using stock BIP341 signatures would subject their signatures to half-aggregation, possibly by accident. Is this a big deal? IDK.

It also places an expected burden of doing half-agg work on the rest of the network, when really it should be the spender's wallet software.

---

A few observations unrelated to the new changes:

Half-aggregation non-interactively reduces n signatures from 64*n bytes to (n+1)*32 bytes

Since the half-agg signature is variable-size scaling with n (the number of signers in the group), does this mean half-agg groups could hit size limits that would put a ceiling on n?

I don't know of any limits applying in this situation. The 520b stack element size limit doesn't apply. The 10000 byte script size limit doesn't apply. Is there some other limit on witness sizes?

Is there a reason you went with this design with a growing variable-size half-agg signature attached to one input, rather than the one i was expecting to see, where you distribute the nonce components across the individual inputs' witnesses?

This approach would have the added bonus that all the keyspend witness elements will become fixed-size (33 bytes for half-agg placeholders, 65 bytes for half-agg finals, i think), making parsing a little easier.