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.