BIP: 460
  Layer: Consensus (soft fork)
  Title: CISA for Taproot Key Path Spends in SegWit v2
  Authors: Fabian Jahr <fjahr@protonmail.com>
  Status: Draft
  Type: Specification
  Assigned: 2026-07-28
  License: CC0-1.0 OR MIT
  Discussion: 2026-07-18: https://groups.google.com/g/bitcoindev/c/1XH6sBLWZuA
  Requires: 340, 341, 458, 459

Introduction

Abstract

This document proposes cross-input signature aggregation (CISA) for Bitcoin transactions. A new witness version (v2) enables Taproot-style key path spending with two Schnorr signature aggregation schemes: half-aggregation and full-aggregation. Half-aggregation non-interactively reduces n signatures from 64*n bytes to (n+1)*32 bytes, while full-aggregation reduces them to a constant 64 bytes but requires interactive signing. Aggregated inputs carry their share of the aggregate signature data and optionally a sighash type, with a marker byte indicating the aggregation mode (half-agg or full-agg) on the last input of each group, while opted-out inputs carry a plain BIP 341 signature. The opt-out mode exists for protocols that depend on a specific signature appearing on chain, such as some adaptor signature protocols.

Copyright

This document, along with the test vector generator and test vectors, is licensed under CC0-1.0 or the MIT License, at your option. The vendored copy of the secp256k1lab library in bip-0460/secp256k1lab is licensed under the MIT License only, as stated in its COPYING file.

Motivation

Signature data makes up a large share of Bitcoin transaction sizes. Each Taproot key path spend requires a 64-byte BIP 340 Schnorr signature, so transactions with many inputs spend much of their weight on signatures.

The linearity of Schnorr signatures allows combining multiple signatures into a more compact form. Cross-input signature aggregation applies this to the signatures of different inputs within one transaction.

This provides:

• Lower fees and smaller transactions: Signature data shrinks with the number of aggregated inputs, reducing transaction weight and fees and freeing up block space
• Reduced cost of privacy: Aggregation reduces the signature cost of any batched transaction, and collaborative transactions such as CoinJoin and PayJoin benefit the most per participant because they batch the inputs of many users
• Flexible usage: Two aggregation schemes serve different use cases and individual inputs can opt out
• Protocol compatibility: The opt-out protects protocols that depend on a specific signature appearing on chain
• Low initial adoption cost: Opted-out spends are plain BIP 341 key path spends, so wallets that do not aggregate can adopt witness v2 outputs without new signing logic

Use cases include:

• CoinJoin/PayJoin transactions: With CISA, the per-participant cost of CoinJoin and PayJoin transactions decreases as the number of participants increases, making privacy-enhancing usage cheaper
• Consolidation and batching: Businesses and users combining many small UTXOs into a single output or multiple payment outputs benefit from reduced transaction costs
• Lightning channel opens and splices: Dual funding and splicing combine inputs from both peers in a collaborative transaction, and the existing interactive negotiation between the peers can accommodate the signing rounds of full-aggregation

Aside from these use cases, any transaction spending more than one witness v2 input benefits from CISA through fee savings.

Design

This BIP introduces a new witness version (v2) that enables signature aggregation for Taproot-style key path spends. The design reuses the existing Taproot and tapscript machinery wherever possible and makes aggregation opt-in on a per-input basis, so witness v2 outputs can be adopted independently of whether aggregation is used. Both aggregation schemes are supported, inputs can opt out, and aggregation is limited to key path spends. The reasoning behind these decisions is covered in the Rationale section.

The main design decision is that every aggregated witness v2 key path input carries only its share of the aggregate signature data plus an optional sighash byte, while opted-out inputs carry a plain BIP 341 signature. The last input in each aggregation group completes the aggregate signature and tags it with a marker byte identifying the scheme. This design:

• Shows which inputs participate in aggregation
• Lets each input specify its own sighash type
• Allows mixing aggregated, opted-out, and non-aggregated inputs in the same transaction
• Commits to the aggregation mode in the signature message, protecting opted-out inputs from non-consensual aggregation by third parties
• Supports half-aggregation and full-aggregation within the same transaction (as separate groups, one per scheme)

Specification

Witness version 2

Witness version 2 outputs are created with a scriptPubKey of OP_2 <32-byte witness program> (or 0x5220{32-byte witness program}).

Validation of witness v2 spends is identical to the witness version 1 rules of BIP 341, with the following modifications for key path spends:

• The single witness stack element remaining after removal of the optional annex is only interpreted as a signature if it is 64 bytes long, or 65 bytes long with a last byte that is not a marker byte. Otherwise its interpretation follows the aggregation forms defined below.
• For inputs that participate in aggregation, the key path signature message and signature verification are replaced by the rules defined below.

All other rules apply unchanged. In particular script path spending and its upgrade mechanisms, annex handling, and the treatment of witness programs that are not exactly 32 bytes long or are wrapped in P2SH follow BIP 341. Signatures inside script path spends are not aggregated under this BIP.

Marker definitions

This BIP defines two marker bytes for the final inputs of the aggregation groups:

• 0xbc: Half-aggregation marker. The input completes the half-aggregation group.
• 0xbd: Full-aggregation marker. The input completes the full-aggregation group.

The marker is the last byte of the final input's witness element. The marker byte is not an opcode, since a key path witness element is not script. The only structural constraint is that markers must be disjoint from the valid sighash types, so that a 65-byte witness element ending in a marker can never be a valid BIP 341 signature. A 64-byte element is always an opted-out signature, since no marked form has that length. The chosen values fall into the range 0xbb to 0xfe, which is unassigned in legacy script and corresponds to OP_SUCCESS opcodes in tapscript, so they do not collide with opcodes commonly seen in scripts.

Opted-out inputs and aggregation group members carry no marker. An opted-out witness element is a 64-byte or 65-byte BIP 341 signature, and member elements are identified by their length. A key path spend whose witness element is neither such a signature nor one of the aggregation forms defined below is invalid. Undefined marker values cannot serve as an upgrade hook because witness data is not committed to by the output. A marker value that validated unconditionally would make every witness v2 output spendable by anyone. Future aggregation modes are therefore expected to be introduced through new witness versions or new leaf versions instead of new marker values.

Witness structure

Aggregation changes only the content of the witness. The transaction format is unchanged. A transaction may contain at most two aggregation groups: one half-aggregation group and one full-aggregation group. Aggregated and non-aggregated inputs can be mixed in any order, with the constraint that all members of a group must appear before the input carrying the group's marker. The input carrying a group's marker is called the final input of the group, all other aggregated inputs are called members. Only witness v2 key path spends can participate in aggregation groups. Inputs spending other output types, as well as witness v2 script path spends and opted-out key path spends, are validated independently under their own rules and can be combined freely with aggregated inputs in the same transaction.

Each witness v2 key path spend uses a single witness element (plus optional annex). For opted-out inputs this element is a 64-byte or 65-byte BIP 341 signature. For aggregated inputs it consists of the input's share of the aggregate signature data, an optional sighash byte, and the marker on the final input:

• Signature data: The 32-byte nonce share for half-aggregation members, nothing for full-aggregation members, and the completion of the aggregate signature for final inputs
• Sighash type: Optional byte following the signature data. If absent, SIGHASH_DEFAULT (0x00) is used¹
• Marker: Last byte of the final input's element (0xbc or 0xbd)

The marker and the length of the witness element together determine its interpretation:

All forms have a fixed length. A witness element whose marker and length combination matches no row of this table is invalid. Opted-out elements have no marker, so a 64-byte element is an opted-out signature even if its last byte equals a marker value, and a 65-byte element is an opted-out signature unless its last byte is a marker. Only 65-byte and 66-byte elements are interpreted against the marker. In the 1-byte and 33-byte member forms the last byte is a sighash byte, so an element of those lengths ending in a marker value is a member with an invalid sighash type.

In all forms with an explicit sighash byte the byte must not be 0x00. SIGHASH_DEFAULT can only be expressed by omitting the sighash byte. This mirrors the rule for 65-byte signatures in BIP 341 and ensures that every signature message has exactly one witness encoding, preventing third parties from malleating the wtxid by switching between equivalent encodings.

Signature message

The signature message of an aggregated input commits to the input's aggregation mode in addition to the transaction data. Let SigMsg(hash_type, ext_flag) be the common signature message function defined in BIP 341, including all of its failure conditions. For an aggregated witness v2 key path spend with sighash type hash_type, the message is computed as:

m = hash_TapSighash(0x01 || agg_mode || SigMsg(hash_type, 0))

The first byte is the sighash epoch. BIP 341 messages use epoch 0x00 and reserve other values for signature algorithms that make invasive changes to how hashing is performed, such as this one. The agg_mode byte is the marker byte of the input's group (0xbc for half-aggregation, 0xbd for full-aggregation). Opted-out inputs use the unchanged BIP 341 message hash_TapSighash(0x00 || SigMsg(hash_type, 0)).²

Committing to the aggregation mode makes aggregation consensual. A signature created for an opted-out input is not valid as a member of an aggregation group and vice versa. Without this commitment any third party could fold an opted-out signature into the half-aggregation group unchanged, because half-aggregation of existing signatures is a public operation. See Why no opt-out marker for details.

Valid sighash types are:

• 0x00: SIGHASH_DEFAULT (only expressible by omitting the sighash byte)
• 0x01: SIGHASH_ALL
• 0x02: SIGHASH_NONE
• 0x03: SIGHASH_SINGLE
• 0x81: SIGHASH_ALL | SIGHASH_ANYONECANPAY
• 0x82: SIGHASH_NONE | SIGHASH_ANYONECANPAY
• 0x83: SIGHASH_SINGLE | SIGHASH_ANYONECANPAY

Note: SIGHASH_ANYONECANPAY composes with aggregation only partially, see Usage of ANYONECANPAY.

Opted-out key path spends

An opted-out witness v2 key path spend has a witness stack containing:

• Without annex: [signature] (64 bytes) or <a href="signature" target="_blank">|| sighash</a> (65 bytes)
• With annex: [signature] [0x50...] or <a href="signature" target="_blank">|| sighash</a> [0x50...]

Validation proceeds exactly as for a BIP 341 key path spend, using the BIP 341 signature message and BIP 340 signature verification against the output key.

Aggregated key path spends

The aggregate signature data of a group is split across the witness elements of its inputs.

Half-aggregation members:

• Without annex: <a href="nonce" target="_blank">share</a> (32 bytes) or <a href="nonce" target="_blank">share || sighash</a> (33 bytes)
• With annex: <a href="nonce" target="_blank">share</a> [0x50...] or <a href="nonce" target="_blank">share || sighash</a> [0x50...]

The nonce share of an input is the first 32 bytes of its individual BIP 340 signature, see Signing.

Half-aggregation final input:

• Without annex: <a href="nonce" target="_blank">share || s || 0xbc</a> (65 bytes) or <a href="nonce" target="_blank">share || s || sighash || 0xbc</a> (66 bytes)
• With annex: <a href="nonce" target="_blank">share || s || 0xbc</a> [0x50...] or <a href="nonce" target="_blank">share || s || sighash || 0xbc</a> [0x50...]

The nonce shares of all group inputs in input order, followed by the s value from the final input, form the (n+1)*32-byte aggregate signature of BIP 458.

Full-aggregation members:

• Without annex: [] (empty element) or [sighash] (1 byte)
• With annex: [] [0x50...] or [sighash] [0x50...]

The empty element is a single witness stack item of length zero. A witness stack without any items remains invalid, see BIP 341.

Full-aggregation final input:

• Without annex: <a href="signature" target="_blank">|| 0xbd</a> (65 bytes) or <a href="signature" target="_blank">|| sighash || 0xbd</a> (66 bytes)
• With annex: <a href="signature" target="_blank">|| 0xbd</a> [0x50...] or <a href="signature" target="_blank">|| sighash || 0xbd</a> [0x50...]

The signature is the 64-byte aggregate signature of BIP 459.

An aggregation group may consist of a single input. In that case the group's only input is its final input.

Validation rules

Witness v2 key path spends are validated in three passes:

Pass 1: Parse and collect aggregation information

For each witness v2 key path spend:

1. Extract annex if present:

• If the witness stack has at least two elements, and the first byte of the last element is 0x50, this last element is the annex and is removed from the witness stack

2. Parse the witness element:

• If the element is 64 bytes long, or 65 bytes long and its last byte is not 0xbc or 0xbd, it is an opted-out signature and is parsed per BIP 341
• Otherwise the length determines the structure per the table above, where 65-byte and 66-byte elements must end in a marker byte. Fail if the combination matches no defined structure
• Extract hash_type and signature data if present
• Verify hash_type is valid (0x01-0x03, 0x81-0x83 in explicit form). Fail on an explicit 0x00

3. Classify input:

• 64-byte or 65-byte signature: Opted-out input
• Empty, 1-byte, 32-byte, or 33-byte element: Aggregation member
• 65-byte or 66-byte element ending in 0xbc or 0xbd: Final input of that marker's group

The structure table is exhaustive, so every witness element that parses successfully falls into exactly one class.

Pass 2: Validate aggregation group structure

Group formation rules:

• The half-aggregation group consists of the 32-byte and 33-byte members and the 0xbc final input
• The full-aggregation group consists of the empty and 1-byte members and the 0xbd final input
• Fail if a group has members but no final input, or more than one final input
• Fail if a member of a group appears after that group's final input
• Opted-out inputs do not form groups

Pass 3: Verify signatures

1. For each opted-out input:

• Compute the message m = hash_TapSighash(0x00 || SigMsg(hash_type, 0)) as in BIP 341
• Verify the 64-byte signature using BIP 340 against the output key (the 32-byte witness program of the spent output)

2. For each aggregation group:

• Collect the group's inputs, consisting of its members and its final input
• Order the group's (pubkey, message) pairs by input index, where the pubkey of each pair is the 32-byte witness program of the spent output
• For each aggregated input i: compute m_i = hash_TapSighash(0x01 || marker || SigMsg(hash_type_i, 0))
• For half-agg: assemble the aggregate signature as the concatenation of the group's nonce shares in input order followed by the s value of the final input
• For half-agg: verify the assembled aggregate signature with VerifyAggregate(aggsig, pm_aggd) as defined in BIP 458, where pm_aggd is the ordered list of pairs
• For full-agg: verify the final input's 64-byte signature with Verify as defined in BIP 459 over the ordered pubkey and message lists

Signing

Signers of aggregated inputs compute the signature message defined above with the marker byte of their group as agg_mode. The secret key is the Taproot tweaked private key corresponding to the 32-byte witness program, derived as in BIP 341.

Opted-out inputs: The signer creates a BIP 341 key path signature exactly as for a Taproot output.

Half-aggregated inputs: Each signer creates an ordinary BIP 340 signature over its message in a single stateless pass. The first 32 bytes of the signature are the input's nonce share, which can be placed in the member's witness element as soon as the signature exists. The s parts of the individual signatures do not appear on chain. Once all signatures of the group are available, any party can combine them with Aggregate or IncAggregate as defined in BIP 458, over the group's pairs ordered by input index, and place the last 32 bytes of the result as the s value in the final input's witness element. The aggregating party should verify the individual signatures first. This identifies a disruptive signer and is necessary because Aggregate does not validate its inputs, see BIP 458.

Full-aggregated inputs: The group's signers run the interactive signing protocol of BIP 459. The public key list of the session is the ordered list of the group's 32-byte witness programs and the message list contains the corresponding signature messages in the same order. Each signer uses its tweaked secret key, see the Key Tweaking section of BIP 459. The 64-byte signature returned by SigAgg is placed in the final input's witness element. Any change that affects a group member's signature message or the group's ordered member list invalidates the session and requires a new one. Secret nonces must never be reused across signing sessions, see BIP 459.

Examples

The final input of each aggregation group carries the marker and the completion of the aggregate signature and therefore more witness weight than the other group members. How this weight difference is accounted for between the participants of a collaborative transaction is a protocol level concern outside the scope of this BIP.

Example 1: Three inputs, all half-aggregated with SIGHASH_DEFAULT

Input 0 witness: [32-byte nonce share]             # 32 bytes: half-agg member
Input 1 witness: [32-byte nonce share]             # 32 bytes: half-agg member
Input 2 witness: [nonce share || s || 0xbc]        # 65 bytes: half-agg final

Total overhead: 1 marker byte
Signature size reduction: 192 bytes → 129 bytes

Example 2: Three inputs full-aggregated with SIGHASH_ALL

Input 0 witness: [0x01]                            # 1 byte: full-agg member, SIGHASH_ALL
Input 1 witness: [0x01]                            # 1 byte: full-agg member, SIGHASH_ALL
Input 2 witness: [64-byte sig || 0x01 || 0xbd]     # 66 bytes: full-agg final, SIGHASH_ALL

Total overhead: 1 marker byte
Signature size reduction: 195 bytes → 68 bytes

Example 3: Witness v1 input alongside a witness v2 aggregation group

Input 0 witness: [64-byte sig]                     # witness v1 (Taproot) key path spend
Input 1 witness: [32-byte nonce share]             # 32 bytes: half-agg member
Input 2 witness: [nonce share || s || 0xbc]        # 65 bytes: half-agg final

Input 0 spends a Taproot output and does not participate in aggregation.
Inputs 1 and 2 form the half-aggregation group.

Total overhead: 1 marker byte
Signature size reduction (v2 inputs): 128 bytes → 97 bytes

Example 4: Mixed transaction

Input 0 witness: [64-byte sig]                     # 64 bytes: opted-out, SIGHASH_DEFAULT
Input 1 witness: [nonce share || 0x03]             # 33 bytes: half-agg member, SIGHASH_SINGLE
Input 2 witness: []                                # empty: full-agg member
Input 3 witness: []                                # empty: full-agg member
Input 4 witness: [nonce share || s || 0xbc]        # 65 bytes: half-agg final
Input 5 witness: [64-byte sig || 0x82]             # 65 bytes: opted-out, SIGHASH_NONE|SIGHASH_ANYONECANPAY
Input 6 witness: [64-byte sig || 0xbd]             # 65 bytes: full-agg final

This transaction has:
- Two opted-out inputs (0, 5) with different sighash types
- One half-aggregation group (inputs 1, 4)
- One full-aggregation group (inputs 2, 3, 6)

Total overhead: 2 marker bytes
Signature size reduction: 450 bytes → 292 bytes

Security

Non-consensual aggregation: The signature message of aggregated inputs commits to the aggregation mode, so third parties cannot move signatures between opted-out witnesses and aggregation groups, see Why no opt-out marker. Signatures also cannot be replayed between witness versions because the signature message always commits to the scriptPubKey of the output being spent.

Adaptor signature incompatibility: Aggregation is incompatible with protocols that extract a secret from a specific signature appearing on chain, most notably some adaptor signature protocols. Adaptor protocols in which the final signature is delivered directly between the parties are not affected. Protocols that rely on on-chain extraction should use opted-out signatures for those inputs.

Shared security of the three modes: Every witness v2 output can be spent through any of the three key path modes, chosen by whoever produces the witness. The security of v2 outputs therefore rests on all three verification algorithms together, and a soundness failure in BIP 340, BIP 458, or BIP 459 would affect all v2 outputs regardless of the mode their owners intended to use. Both aggregation schemes come with security proofs that reduce to established assumptions in the same discrete logarithm setting as BIP 340, see the security discussions in BIP 458 and BIP 459.

Witness malleability: For key path spends every witness element size is fixed by consensus and the annex is committed by the signature message, so third parties cannot change the weight of a fully signed input. Given the nonce shares of a group, only one value of s satisfies the verification equation, and replacing a nonce share requires knowledge of the individual signatures. Third parties therefore cannot malleate witness v2 key path witness data. Opted-out inputs carry plain BIP 340 signatures, which are non-malleable.

Transaction level verification: Aggregated inputs add one transaction level verification step per aggregation group, while parsing, structure checks, opted-out inputs, and script path spends remain per-input operations. Implementations that parallelize script validation per input can schedule the group verification as one additional check. Existing wtxid based validation caches remain correct since any witness change alters the wtxid. Aggregate verification can also join verification batches together with individual BIP 340 signatures, so aggregation does not preclude batch validation.

Computation limits: Aggregation does not increase the worst-case signature verification cost of a block. Full-aggregation requires about half the elliptic curve multiplications per input of individual BIP 340 verification, while half-aggregation requires about the same number in a single batchable equation. The densest packing of signature verification work per weight unit remains tapscript under the BIP 342 validation weight budget, which this BIP does not change.A minimal Taproot key path input weighs 230 weight units, 164 for the input base data plus 66 for the witness element, and BIP 340 verification costs two elliptic curve multiplications per signature. Per member of a large group, full-aggregation accounts for 166 weight units and half-aggregation for 198 weight units including the member's 32-byte nonce share, ignoring small per-group constants. The BIP 459 verification equation costs n+1 multiplications for a group of n inputs, while the BIP 458 equation costs about 2n since the randomizers multiply both the nonce point and the challenge term of each member. Ignoring transaction overhead, a block filled with minimal full-aggregation members needs about 4,000,000 / 166 ≈ 24,100 multiplications and one filled with minimal half-aggregation members about 2 * 4,000,000 / 198 ≈ 40,400, compared to 2 * 4,000,000 / 230 ≈ 34,800 for minimal Taproot key path spends. The half-aggregation count is about 16 percent higher, but its per-input cost matches batch verified BIP 340 signatures and the whole group is verified as one multi-scalar multiplication, which is faster in practice than the same number of independent verifications. All of these remain far below the BIP 342 validation weight budget, which admits one tapscript signature verification per 50 weight units, or 80,000 verifications with about 160,000 multiplications per block. Aggregation also does not increase the maximum number of inputs per block, since an input spending an output that requires no signature, such as a bare OP_TRUE script, weighs only 164 weight units today.

Mode fingerprinting: The aggregation mode of every input is visible on chain from its witness element, so distinctive mode combinations can fingerprint the wallets or protocols that created a transaction. Participants of collaborative transactions should prefer one mode for all participating inputs if they want to avoid this.

Test vectors

Wallet operation vectors covering scriptPubKey and address computation, signature message computation, and witness construction for both key path and script path spending can be found in wallet-test-vectors.json.

Transaction level validity cases, including marker parsing failures, group structure failures, annex handling, script path spending, and the aggregation mode commitment, can be found in consensus-test-vectors.json.

Both files are generated by test-vectors.py, which builds on the reference code of BIP 458 and BIP 459. All vectors use deterministic test-only keys and nonces, and BIP 340 signatures are created with an all-zero auxiliary randomness array, except one vector that deterministically searches auxiliary randomness values to produce a signature ending in a marker byte.

Reference implementation

A work in progress implementation for Bitcoin Core is available at https://github.com/fjahr/bitcoin/tree/bip460. It implements the validation rules of this BIP and validates all consensus test vectors.

Rationale

Why a new witness version?

A new witness version is necessary because BIP 341 completely specifies the validation rules for witness v1, fixing key path witnesses to 64-byte or 65-byte signatures. The aggregation witness forms used by this BIP are invalid under those rules, and a soft fork can only turn valid transactions into invalid ones, not the reverse. Aggregation therefore cannot be retrofitted onto existing Taproot outputs.

Why the marker-based design?

The primary alternative to markers is a design without them, where aggregated inputs carry only a 1-byte sighash placeholder and aggregation applies to all witness v2 inputs of a transaction or to none of them. Compared to that alternative the markers cost one byte per aggregation group. In exchange the marker provides three properties:

Per-input consent: An all-or-nothing design couples the choices of unrelated parties. In a CoinJoin a single participant that requires a plain on-chain signature, for example for an adaptor signature based protocol, would force every other participant to forgo aggregation. With markers this choice is local to the input, which matters most in exactly the multi-party transactions that CISA is designed to make cheaper.

Self-describing witnesses: Every input is classified locally by the length and last byte of its witness element instead of inferring a transaction-wide mode from the shape of all witnesses. This avoids inference edge cases. For example, in the placeholder design the final aggregated input's witness consists of a sighash byte followed by the aggregate signature as a separate element, and an aggregate signature whose first byte happens to be 0x50 is misparsed as an annex under the BIP 341 annex rule. Roughly one in 256 honestly generated aggregate signatures would hit this case and force the signers to start over. In this design the signature data of every input is part of its single witness element, which the annex rule never inspects, so no signature data can be misparsed as an annex.

Two coexisting groups: A transaction can contain one half-aggregation group and one full-aggregation group at the same time. This allows a tightly coordinated subset of signers, for example the inputs of a single wallet, to use full-aggregation while the remaining inputs of a collaborative transaction use half-aggregation.

Group members carry no marker, since the member element lengths are disjoint from all other forms and the length alone classifies them. Half-aggregation members carry their nonce share directly instead of contributing to a growing aggregate signature on the final input. This makes every witness element form fixed-size and distributes the witness weight of the aggregate evenly across the group's inputs. Only the final inputs need a marker, because the completion of an aggregate signature is indistinguishable from a BIP 341 signature by content.

A more flexible alternative with multiple aggregation groups per scheme, similar to the bucket concept from early aggregation discussions, was rejected. Multiple groups would only benefit full-aggregation, since half-aggregation groups can be merged by anyone after signing. They would allow several smaller signing sessions instead of one session spanning all aggregated inputs, for example through a group number encoded in the marker byte. However, with SIGHASH_DEFAULT the signers of every group still have to agree on the complete output list of the transaction before signing, making coordination across groups necessary. Decoupling the groups through SIGHASH_SINGLE with SIGHASH_ANYONECANPAY is limited to groups of signers with a single input and output each, reveals which input pays which output, and lets anyone split the merged transaction apart again. Half-aggregation already provides this flexibility without any joint signing session at a cost of 32 weight units per input, and a separate transaction per group provides it at the cost of repeating the transaction overhead. Group numbers would also reveal which inputs belong together, which has negative privacy implications.

Why no opt-out marker?

The main motivation for the unmarked opt-out is compatibility with BIP 341. 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. Leaving out the marker also saves one byte per opted-out input.

Opted-out inputs still need protection from non-consensual aggregation. Half-aggregation of existing signatures is a public operation. Any third party in possession of valid BIP 340 signatures, such as a miner or a relaying node, can aggregate them without the signers' involvement. Some protocols depend on a specific signature appearing on chain. Most notably, some adaptor signature protocols extract a secret from the difference between an on-chain signature and a previously shared adaptor signature, and this extraction becomes impossible once the signature has been folded into an aggregate.

For this protection the separation of the signature messages is sufficient. An opted-out signature is created over the BIP 341 message and is therefore useless as an aggregation group member, and vice versa. Aggregation is consensual for every input.

An explicit opt-out marker would serve parsing rather than protection, distinguishing a 65-byte opted-out signature with a sighash byte from an aggregation group final without one. Markers in the position of the sighash byte resolve this ambiguity without marking opted-out inputs, since marker values are disjoint from valid sighash values. A small caveat is that a future witness version that keeps the witness v2 rules cannot use the marker values as sighash types.

A consequence of the mode commitment is that the aggregation mode is chosen at signing time. A signature created for aggregation cannot later be used as a standalone opted-out signature either, so signers that want to keep both options open must produce two signatures. Planning for aggregation costs one weight unit if the group ends up with a single member, since the single-member group signature carries the marker.

Why two aggregation schemes?

Half-aggregation and full-aggregation serve different use cases:

Full-aggregation offers roughly twice the savings of half-aggregation but requires all signers to run a stateful two-round protocol within one signing session. Mishandling the secret nonce state between the rounds can lead to key extraction, which makes supporting it on hardware signers and air-gapped devices demanding. The slow adoption of MuSig2 by signing devices illustrates this cost.

Half-aggregation signers produce plain BIP 340 signatures in a single stateless pass, and the aggregation happens downstream of all signing. This fits existing asynchronous multi-party workflows, for example PSBT based signing ceremonies where cosigners are available at different times, or BIP 77 Async Payjoin where sender and receiver are not required to be online at the same time. It also avoids giving every participant of a large collaborative transaction a second opportunity to stall the protocol between signing rounds. 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.

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 use simple key path spends. Aggregating signatures from within scripts, in contrast, conflicts with the tapscript upgrade mechanisms. Whether a signature operation contributes to the transaction level aggregate depends on script execution, but a script containing an OP_SUCCESS opcode succeeds without being executed. 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 the 2018 aggregation discussion by Anthony Towns, whose mitigations rely on execution order, which the parse time OP_SUCCESS 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 upgrade semantics.

Usage of ANYONECANPAY

This BIP permits all standard sighash types at the consensus level, including SIGHASH_ANYONECANPAY (0x80 flag). Whether to aggregate is an application level decision, not a consensus concern, so the consensus rules stay permissive.

Full-aggregation: The signing session of BIP 459 fixes the group's public key and message lists, so the membership of a full-aggregation group cannot grow after signing has started. ANYONECANPAY still composes with full-aggregation in one direction. Once the group members have signed with ANYONECANPAY, additional opted-out, half-aggregated, or non-v2 inputs can be appended to the transaction without invalidating the group, because the group's messages do not commit to those inputs. Only extending the full-aggregation group itself with later inputs is impossible.

Half-aggregation: Half-aggregation composes with ANYONECANPAY directly. Signers create their signatures over the half-aggregation flavored message at signing time, further inputs are added later, and once the input set is final anyone can aggregate the collected signatures without further involvement of the signers.

Future considerations

Block-wide aggregation: Block-wide aggregation remains a potential future optimization and is not precluded by this design. Opted-out inputs do not necessarily signal that the signer needs the signature on chain unaggregated, since there may be other motivations such as simple adoption, so such a design would probably need its own explicit opt-out.

Script path aggregation: Script path aggregation can be specified in a separate BIP and added in the same or a future soft fork.

Deployment

This BIP is to be deployed by a soft fork activation mechanism. The activation parameters are to be determined and will be specified in a future update of this document. Since other proposals also target witness version 2, the witness version is subject to coordination and may change in a future update as well.

Backward compatibility

Non-upgraded nodes

Nodes that have not upgraded to support witness v2 treat witness v2 outputs as anyone-can-spend, per the BIP 141 unknown witness version rule. Depending on their policy settings, such nodes might not relay witness v2 transactions or include them in blocks.

Non-upgraded wallets

Wallets without witness v2 support cannot create or spend witness v2 outputs but can send to witness v2 addresses if they support Bech32m.

Acknowledgements

Thanks to Vojtěch Strnad for feedback on early versions of this BIP, in particular for prompting a precise description of the script path aggregation obstacles and for streamlining the specification. Thanks to conduition for suggesting the distribution of the half-aggregation signature data across the group's witness elements.

Footnotes

1. ^ Why does the marker follow the sighash byte and the signature data? Traditionally the sighash byte is appended to the signature, as in the 65-byte signatures of BIP 341, and this BIP keeps that order. Placing the marker last, in the position of the sighash byte, is what allows opted-out inputs to use unchanged BIP 341 signatures. A 65-byte element ending in a valid sighash byte is an opted-out signature and one ending in a marker is an aggregation group final, and no marked form is 64 bytes long. With the marker in front, a 65-byte element could be either an opted-out signature with a sighash byte or a full-aggregation final without one.
2. ^ Why do opted-out inputs keep sighash epoch 0x00? The epoch identifies the message computation, not the witness version, and other values are reserved for algorithms that change how hashing is performed. Opted-out spends leave the computation unchanged, so a different epoch would force wallets that do not aggregate to implement a second signing code path without a security benefit. Replaying the resulting signatures across witness versions is not possible because SigMsg commits to the scriptPubKey of the output being spent. Keeping epoch 0x00 also means that a hypothetical witness v2 output type following the BIP 341 rules unchanged would produce the exact same key path spends as the opt-out mode of this BIP.