Bitcoin Devs Merge Three BIPs Targeting Cheaper Signature Payloads

Bitcoin developers have merged three new Bitcoin Improvement Proposals, including signature-aggregation specifications that could reduce signature payloads by up to 90% and cut certain transaction fees by as much as 27.3%.

The merged proposals center on aggregating BIP-340 Schnorr signatures. For ten signatures, aggregation shrinks 640 bytes of signature data to 352 bytes under half-aggregation or 64 bytes under full aggregation. That is a 45% and 90% reduction respectively, measured before encoding overhead. The saving on a full transaction's fee is smaller, since signatures are only one component of transaction size.

How much do fees actually fall?

Bitcoin fees are expressed per virtual byte (vB), where virtual size equals transaction weight divided by four and rounded up. The proposal's hypothetical examples place all inputs in one eligible aggregation group, use default signing settings, 34-byte output scripts and no optional annex data, while including transaction overhead, witness encoding and the group's marker byte.

The results differ sharply by transaction type:

• Joint transaction, 10 inputs and 10 outputs: size falls from 1,016 vB to 944 vB with half-aggregation or 872 vB with full aggregation, a fee reduction of about 7.1% or 14.2%. At an illustrative 10 satoshis per vB, that saves 720 or 1,440 satoshis.
• Consolidation, 100 inputs into one output: size drops from 5,804 vB to 5,012 vB with half-aggregation or 4,220 vB with full aggregation, cutting fees by approximately 13.6% or 27.3%.

Consolidation therefore benefits most, which matters for exchanges and custodians that regularly batch many inputs into single outputs. Aggregation rewards exactly the high-input transactions those operators produce at scale.

What has to change before activation?

BIP460 leaves activation parameters unspecified. Its proposed witness version, currently v2, requires coordination with other pending proposals before deployment.

Wallets must add support for the new output type, because existing Taproot outputs do not automatically gain aggregation. Aggregation is limited to direct signature-based spends, meaning key-path spends. Script-path spends, which execute scripts, cannot join aggregation groups, and eligible inputs retain the ability to opt out.

What are the operational costs?

The two aggregation modes impose different engineering burdens. Full aggregation requires a stateful two-round signing protocol. Reusing secret nonces within that protocol can expose signing keys, which makes hardware-wallet and air-gapped support demanding to implement safely.

Half-aggregation avoids the joint signing session entirely, though collaborative transaction construction still requires agreement among participants. The trade-off is structural: full aggregation delivers the larger savings but carries the heavier operational risk.

For wallet vendors and custody providers, the near-term decision is whether to build aggregation support into signing infrastructure before activation parameters settle. The proposals now sit in the merged BIP repository awaiting that coordination, and any mainnet effect on fee markets depends on wallet adoption rates that the specifications alone cannot drive.

By Tom Whitfield