Half-Aggregation

What Is Half-Aggregation?

Half-aggregation is a cryptographic technique that combines multiple independent Schnorr signatures into a single, shorter aggregate signature. Each standard BIP 340 Schnorr signature consists of two 32-byte components: a nonce commitment (R) and a scalar (s). Half-aggregation keeps all n nonce commitments intact but compresses the n scalar values into a single 32-byte sum. The result is an aggregate of (n + 1) × 32 bytes instead of n × 64 bytes.

The "half" in the name refers to the fact that only the scalar half of each signature is aggregated. The nonce commitments cannot be combined without signer interaction, so they remain individually present. This tradeoff is what makes the scheme non-interactive: because the R values are untouched, a third party can perform the aggregation after signatures have already been created.

The idea was first proposed by Tadge Dryja on the Bitcoin development mailing list in 2017 in the context of block-wide signature aggregation. The formal cryptographic treatment came in a 2021 paper by Chalkias, Garillot, Kondi, and Nikolaenko, which proved the security of non-interactive half-aggregation for EdDSA and variants of Schnorr signatures. Blockstream researchers later adapted the scheme specifically for BIP 340 signatures used in Bitcoin, culminating in draft BIP 458.

How It Works

A standard BIP 340 Schnorr signature on a message m with public key P is a pair (R, s), where R is the signer's nonce commitment (a curve point, encoded as 32 bytes) and s is the scalar response (also 32 bytes). Verification checks that s · G equals R + H(R, P, m) · P, where G is the generator point and H is a tagged hash function.

Half-aggregation works by linearly combining the scalar components using random-looking coefficients derived from the set of signatures being aggregated:

1. Collect n valid signatures (R₁, s₁), (R₂, s₂), …, (Rₙ, sₙ) along with their corresponding public keys and messages
2. Compute aggregation coefficients z₁, z₂, …, zₙ by hashing all the public keys, messages, and nonce commitments together (the first coefficient z₁ is typically set to 1)
3. Compute the aggregate scalar: s_agg = z₁ · s₁ + z₂ · s₂ + … + zₙ · sₙ
4. Output the half-aggregate signature as (R₁, R₂, …, Rₙ, s_agg)

The verifier recomputes the same coefficients and checks a single multi-scalar multiplication instead of n independent signature verifications.

Size Savings

The aggregate signature contains n nonce commitments (32 bytes each) plus one aggregate scalar (32 bytes), totaling 32n + 32 bytes. Compare this with the n × 64 bytes needed for individual signatures:

As n grows, the savings asymptotically approach 50%, because the single aggregate scalar becomes negligible relative to the n preserved nonce commitments.

Incremental Aggregation

An important property of half-aggregation is that it supports incremental aggregation: new signatures can be folded into an existing half-aggregate without re-processing the original signatures. A relay node, for example, could maintain a running half-aggregate and append each new transaction's signature as it enters the mempool. This makes the scheme practical for block construction, where signatures arrive over time rather than all at once.

Verification

Verifying a half-aggregate signature requires access to all n public keys, messages, and nonce commitments. The verifier recomputes the aggregation coefficients and checks:

s_agg · G == z₁ · (R₁ + H(R₁, P₁, m₁) · P₁)
             + z₂ · (R₂ + H(R₂, P₂, m₂) · P₂)
             + ...
             + zₙ · (Rₙ + H(Rₙ, Pₙ, mₙ) · Pₙ)

This is a single multi-scalar multiplication, which can be computed more efficiently than n separate signature verifications using techniques like batch verification algorithms (Pippenger or Straus).

Half-Aggregation vs. Full Aggregation

Full aggregation schemes like MuSig2 and FROST compress n signatures into a single 64-byte signature regardless of input count. This is maximally space-efficient but requires interactive coordination among signers during the signing process.

These two approaches are complementary, not competing. In the CISA proposal, transaction builders who can coordinate signers would use full aggregation (DahLIAS) for maximum savings, while block producers would use half-aggregation to further compress signatures across transactions without any signer involvement.

Use Cases

Cross-Input Signature Aggregation (CISA)

The primary motivation for half-aggregation is CISA: aggregating signatures across multiple inputs in a Bitcoin transaction. Today, each input carries its own 64-byte Schnorr signature. With half-aggregation, a transaction with 5 key-path Taproot inputs could replace 320 bytes of signatures with a single 192-byte aggregate, saving 128 bytes (40%) of signature data.

For the average historical Bitcoin transaction, half-aggregation would yield approximately 20% total byte savings when accounting for non-signature witness data that remains unchanged. Read more in the CISA deep dive.

Block-Level Aggregation

Because half-aggregation is non-interactive, miners or block builders could aggregate all signatures in a block into a single half-aggregate. A block containing 2,000 single-input transactions with Schnorr signatures would compress 128,000 bytes of signature data to roughly 64,032 bytes. This would reduce block weight and allow more transactions per block without increasing the block size limit.

Privacy-Enhancing Transactions

Protocols like CoinJoin and PayJoin create transactions with many inputs from different participants. These participants typically cannot coordinate an interactive signing session for full aggregation. Half-aggregation lets a coordinator compress all their independent signatures after collection, reducing the cost premium that currently discourages privacy-enhancing transactions.

UTXO Consolidation

Wallets that accumulate many small UTXOs periodically consolidate them into fewer outputs. A consolidation transaction with 20 inputs would save 45% on signature data through half-aggregation, making consolidation cheaper and reducing the number of stranded UTXOs in the network.

Why It Matters

Block space on Bitcoin is scarce and expensive. Signatures currently account for a significant portion of transaction weight, especially for multi-input transactions. Half-aggregation offers a way to reclaim nearly half of that space without requiring any change to how users create signatures: the aggregation happens after the fact, transparently.

For Layer 2 protocols and Bitcoin-native scaling solutions, cheaper on-chain footprints directly improve economics. Channel opens, closes, and settlement transactions on networks like Lightning and protocols like Spark benefit from lower on-chain costs whenever multi-input transactions are involved. Reduced transaction weight also lowers the minimum economically viable UTXO value, improving dust limit thresholds across the network.

Risks and Considerations

Requires a Soft Fork

Half-aggregation changes how signatures are verified at the consensus level. Existing nodes cannot validate half-aggregate signatures without a protocol upgrade. The CISA proposal (a separate draft BIP building on BIP 458 and BIP 459) would introduce a new witness version to enable aggregated signatures. Like all consensus changes, this requires broad community agreement and careful review.

No Script-Path Support

Current CISA proposals limit aggregation to key-path spends. Script-path spends (where a Taproot input reveals a script from the TapTree) are excluded because aggregation would conflict with the OP_SUCCESS upgrade mechanism used for future script opcodes.

Non-Extractability

Individual signatures cannot be extracted from a half-aggregate. Once signatures are combined, you cannot recover any single original signature from the aggregate. This is a security feature (it prevents forging new valid aggregates from parts of old ones), but it means that systems relying on individual signature availability must aggregate only at the appropriate stage. If a transaction needs to be modified after aggregation, the affected signatures must be re-created.

Verification Cost

While half-aggregation saves space, verification of the aggregate requires a multi-scalar multiplication across all n public keys and nonce commitments. For very large aggregates (such as full-block aggregation with thousands of signatures), the computational cost of verification may increase compared to the parallelizable verification of individual signatures. In practice, efficient multi-scalar multiplication algorithms keep this overhead manageable.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.