BIP draft: CISA for Taproot Key Path Spends #2212

   6 | +  Status: Draft
   7 | +  Type: Specification
   8 | +  Assigned: ?
   9 | +  License: BSD-3-Clause
  10 | +  Discussion: 2026-07-18: https://groups.google.com/g/bitcoindev/c/1XH6sBLWZuA
  11 | +  Requires: 340, 341, 342, 458, 459

vostrnad commented at 9:12 PM on July 21, 2026:

I don't think this requires BIP-342, BIP-341 didn't require it either.

  70 | +
  71 | +=== Witness version 2 ===
  72 | +
  73 | +Witness version 2 outputs are created with:
  74 | +
  75 | +* '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>)

vostrnad commented at 9:12 PM on July 21, 2026:

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).

  71 | +=== Witness version 2 ===
  72 | +
  73 | +Witness version 2 outputs are created with:
  74 | +
  75 | +* '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>)
  76 | +* '''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.

vostrnad commented at 9:13 PM on July 21, 2026:

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.

  73 | +Witness version 2 outputs are created with:
  74 | +
  75 | +* '''ScriptPubKey''': <code>OP_2 <32-byte x-only pubkey></code> (or <code>0x5220{32-byte x-only pubkey}</code>)
  76 | +* '''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.
  77 | +
  78 | +The 32-byte x-only pubkey is computed identically to [[bip-0341.mediawiki|BIP 341]] Taproot outputs.

vostrnad commented at 9:13 PM on July 21, 2026:

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.

  86 | +* '''Script path spend''': The witness stack contains two or more elements after removal of the optional annex. Validation follows the script path spending rules of BIP 341 and [[bip-0342.mediawiki|BIP 342]] unchanged. Signatures inside script path spends are not aggregated under this BIP.
  87 | +
  88 | +Script path signatures continue to use the unmodified BIP 341 signature message with epoch <code>0x00</code> and the BIP 342 tapscript extension.
  89 | +The aggregation mode commitment defined below applies only to key path spends.
  90 | +Signatures cannot be replayed between witness versions because the signature message always commits to the scriptPubKey of the output being spent.
  91 | +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.

vostrnad commented at 9:13 PM on July 21, 2026:

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.

 411 | +== Reference implementation ==
 412 | +
 413 | +A work in progress implementation for Bitcoin Core is available at https://github.com/fjahr/bitcoin/tree/2026-07-cisa-txwide.
 414 | +It implements the validation rules of this BIP and validates all consensus test vectors.
 415 | +
 416 | +== Rationale ==

vostrnad commented at 9:13 PM on July 21, 2026:

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.

 493 | +Finally, half-aggregation composes with workflows where the input set is still growing after signing has started, such as ANYONECANPAY based fee bumping, because aggregation can happen once the set is final.
 494 | +
 495 | +=== Why key path only? ===
 496 | +
 497 | +Key path spends have one signature per input that is visible from the witness structure alone, which makes their aggregation rules simple.
 498 | +The use cases motivating this BIP, collaborative transactions and consolidations, also typically spend simple key path outputs.

vostrnad commented at 9:13 PM on July 21, 2026:

The use cases motivating this BIP, collaborative transactions and consolidations, also typically spend simple key path inputs.

 546 | +=== Taproot compatibility ===
 547 | +
 548 | +Witness v2 coexists with witness v1 (Taproot):
 549 | +
 550 | +* Transactions can mix witness v1 and v2 inputs
 551 | +* The same keys and HD derivation paths can be used for both, subject to the usual privacy considerations of key reuse

vostrnad commented at 9:13 PM on July 21, 2026:

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.)

 550 | +* Transactions can mix witness v1 and v2 inputs
 551 | +* The same keys and HD derivation paths can be used for both, subject to the usual privacy considerations of key reuse
 552 | +
 553 | +== Acknowledgements ==
 554 | +
 555 | +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.

vostrnad commented at 9:13 PM on July 21, 2026:

I'd prefer to be credited like this if it's not too much trouble:

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.

 499 | +Aggregating signatures from within scripts, in contrast, conflicts with the tapscript upgrade mechanisms.
 500 | +Whether a signature operation contributes to the transaction level aggregate depends on script execution, but a script containing an <code>OP_SUCCESS</code> opcode succeeds without being executed.
 501 | +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.
 502 | +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.
 503 | +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.
 504 | +Solving these questions is left for a separate BIP with its own leaf version and upgrade semantics.

vostrnad commented at 9:19 PM on July 21, 2026:

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.