Bitcoin's proposal repository added three draft specifications on Nov. 2-4 that could lower fees for payments assembled jointly by multiple users and for consolidating many inputs into one output.
BIP458 merged on Nov. 2, BIP459 on Nov. 3 and BIP460 on Nov. 4. Their mechanism combines the signatures attached to transaction inputs, the coins being spent.
How signature aggregation works
Half-aggregation combines independently produced signatures without an interactive signing session: n signatures of 64 bytes become 32(n+1) bytes. Full aggregation requires coordinated signing but produces a single 64-byte signature for all aggregated signatures in a group.
For ten signatures, that means shrinking 640 bytes to 352 bytes or 64 bytes, respectively. That is a 45% and 90% reduction in signature payload before encoding overhead. The reduction in the whole transaction's fee would be much smaller.
Modeled fee reductions
Bitcoin fees are commonly expressed per virtual byte (vB). Under Bitcoin's weight rules, virtual size is transaction weight divided by four, rounded up.
The hypothetical examples put all inputs in one eligible aggregation group and use default signing settings, 34-byte output scripts and no optional extra witness data, or annex. Transaction overhead, witness encoding and the group's marker byte are included.
A joint transaction with ten inputs and ten outputs would shrink from 1,016 vB to 944 vB with half-aggregation or 872 vB with full aggregation, lowering its fee by about 7.1% or 14.2%. At an illustrative 10 satoshis per vB, the savings would be 720 or 1,440 satoshis.
Consolidation benefits more in the second example of 100 inputs combined into one output. Its size falls 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%.
The input/output mix changes the fee benefit. The draft proposals still require a soft fork and wallet support.
Activation and wallet requirements
BIP460 leaves activation parameters unspecified, and its proposed witness version, currently v2, needs coordination with other proposals.
Wallets would need to support the new output type, as existing Taproot outputs would not automatically gain aggregation, which is limited to direct signature-based or key-path spends.
Spends that execute scripts, known as script-path spends, cannot join aggregation groups, and eligible inputs can opt out.
Full aggregation needs a stateful two-round signing protocol, and reusing secret nonces can expose signing keys, making hardware and air-gapped support demanding. Half-aggregation avoids that joint signing session, although collaborative transaction construction still requires agreement.
