BIP draft: CISA for Taproot Key Path Spends#2212
Conversation
Add a vendored copy of the secp256k1lab library (master branch, commit a265da139aea27386085a2a8760f8698e1bda64e) that the full-aggregation reference implementation and test vector scripts depend on.
|
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
left a comment
vostrnad
left a comment
There was a problem hiding this comment.
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.
| Assigned: ? | ||
| License: BSD-3-Clause | ||
| Discussion: 2026-07-18: https://groups.google.com/g/bitcoindev/c/1XH6sBLWZuA | ||
| Requires: 340, 341, 342, 458, 459 |
There was a problem hiding this comment.
I don't think this requires BIP-342, BIP-341 didn't require it either.
|
|
||
| Witness version 2 outputs are created with: | ||
|
|
||
| * '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>) |
There was a problem hiding this comment.
Since we're in the specification section, saying that the 32-byte witness program is a public key introduces a tiny bit of ambiguity as to whether the following validation rules apply when the witness program isn't a valid public key (i.e. x-coordinate of a valid curve point).
| Witness version 2 outputs are created with: | ||
|
|
||
| * '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>) | ||
| * '''Address format''': Bech32m encoding with prefix <code>bc1</code> (mainnet) or <code>tb1</code> (testnet). Addresses start with <code>bc1z</code> and <code>tb1z</code> respectively. |
There was a problem hiding this comment.
Since addresses are a standard that exists outside of consensus rules, I'd mention them in a different section. You could also not mention them at all since BIP350 already pre-specifies what the address format for SegWit v2 outputs is, and that way you'd have one less thing to worry about should you ever change it to SegWit v3 or something else.
| * '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>) | ||
| * '''Address format''': Bech32m encoding with prefix <code>bc1</code> (mainnet) or <code>tb1</code> (testnet). Addresses start with <code>bc1z</code> and <code>tb1z</code> respectively. | ||
|
|
||
| The 32-byte x-only pubkey is computed identically to [[bip-0341.mediawiki|BIP 341]] Taproot outputs. |
There was a problem hiding this comment.
What is this even supposed to mean? In any case, the specification section in a consensus change BIP should be highly focused on the validation rules, so this feels out of place anyway.
| Script path signatures continue to use the unmodified BIP 341 signature message with epoch <code>0x00</code> and the BIP 342 tapscript extension. | ||
| The aggregation mode commitment defined below applies only to key path spends. | ||
| Signatures cannot be replayed between witness versions because the signature message always commits to the scriptPubKey of the output being spent. | ||
| The upgrade mechanisms of BIP 341 and BIP 342, unknown leaf versions and <code>OP_SUCCESS</code> opcodes, apply to witness v2 script path spends unchanged. |
There was a problem hiding this comment.
This feels like too much text for describing the simple fact that script path validation rules are unchanged between SegWit v1 and v2. I feel the same about other parts of the specification section, and I think it would be great to base the whole specification on the fact that validation of v2 spends is identical to v1 except for a concrete list of differences. You could then remove or simplify other text that just reiterates this, like the annex handling section or the invalid empty witness point below.
| A work in progress implementation for Bitcoin Core is available at https://github.com/fjahr/bitcoin/tree/2026-07-cisa-txwide. | ||
| It implements the validation rules of this BIP and validates all consensus test vectors. | ||
|
|
||
| == Rationale == |
There was a problem hiding this comment.
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.
| === Why key path only? === | ||
|
|
||
| Key path spends have one signature per input that is visible from the witness structure alone, which makes their aggregation rules simple. | ||
| The use cases motivating this BIP, collaborative transactions and consolidations, also typically spend simple key path outputs. |
There was a problem hiding this comment.
| The use cases motivating this BIP, collaborative transactions and consolidations, also typically spend simple key path outputs. | |
| The use cases motivating this BIP, collaborative transactions and consolidations, also typically spend simple key path inputs. |
| Witness v2 coexists with witness v1 (Taproot): | ||
|
|
||
| * Transactions can mix witness v1 and v2 inputs | ||
| * The same keys and HD derivation paths can be used for both, subject to the usual privacy considerations of key reuse |
There was a problem hiding this comment.
Using the same HD derivation paths for both SegWit v1 and v2 seems like a bad idea for multiple reasons. (I think the whole Taproot compatibility section can be removed, pointing out that you can have v1 and v2 inputs in the same transaction feels very much redundant.)
|
|
||
| == Acknowledgements == | ||
|
|
||
| Thanks to vostrnad for feedback on an early version of this BIP, in particular for prompting a precise description of the script path aggregation obstacles. |
There was a problem hiding this comment.
I'd prefer to be credited like this if it's not too much trouble:
| Thanks to vostrnad for feedback on an early version of this BIP, in particular for prompting a precise description of the script path aggregation obstacles. | |
| Thanks to Vojtěch Strnad for feedback on an early version of this BIP, in particular for prompting a precise description of the script path aggregation obstacles. |
| A later soft fork redefining such an opcode would change which signatures the aggregate has to cover, so transactions valid under the new rules would be invalid for older nodes, turning the redefinition into a hard fork. | ||
| This is a variant of the problem described in [https://gnusha.org/pi/bitcoindev/20180321040618.GA4494@erisian.com.au/ the 2018 aggregation discussion by Anthony Towns], whose mitigations rely on execution order, which the parse time <code>OP_SUCCESS</code> semantics of tapscript do not provide. | ||
| Script execution raises further design questions, for example the BIP 342 sigops budget assumes 50 witness weight units per signature check and would be exhausted by short placeholder signatures, and the aggregate signature must be located before execution while group membership only becomes known during it. | ||
| Solving these questions is left for a separate BIP with its own leaf version and upgrade semantics. |
There was a problem hiding this comment.
In "Future considerations" you say: "Script path aggregation can be specified in a separate BIP and added in the same or a future soft fork." But here it says it would have its own leaf version, which is not necessary if it's added in the same soft fork.
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 “version 2 (or the next unencumbered version available when this proposal is deployed)” or something 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. |
4 participants
This is a BIP draft for cross-input signature aggregation (CISA) of BIP340 signatures. 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_SUCCESSupgrade 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.