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.
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 or 64 bytes, respectively. That’s a 45% and 90% reduction in signature payload, before encoding overhead. The reduction in the whole transaction’s fee would be much smaller.
Reducing Bitcoin transaction fees
Bitcoin fees are commonly expressed per virtual byte (vB). Under Bitcoin’s weight rules, virtual size is transaction weight divided by four, rounded up.
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%.
Signature payload for ten signaturesSeparate signatures use640 bytes. Half uses352; full uses64. Encoding excluded.01 / TEN SIGNATURES, BEFORE ENCODINGSeparate640 bytesHalf aggregate352 bytes45% less signature dataFull aggregate64 bytes90% less signature dataPayload compression alone does not measure the whole transaction fee.
Signature payload for ten signaturesSeparate signatures use640 bytes. Half uses352; full uses64. Encoding excluded.01 / TEN SIGNATURESSeparate640 bytesHalf aggregate352 bytes45% less signature dataFull aggregate64 bytes90% less signature dataSignature payload only; before encoding.
Choose a hypothetical transaction
Choose a hypothetical transactionJoint paymentConsolidation
10 inputs, 10 outputs. Many outputs leave less of the transaction available for signature compression.
Whole fee comparison, 10 inputs and 10 outputsHypothetical eligible inputs, default signing, no annex,34-byte output scripts. Geometry shows weight; labels show rounded vB. Same fee rate.02 / WHOLE TRANSACTION, INCLUDING ENCODINGSeparate1,016 vBHalf aggregate944 vB7.1% lower feeFull aggregate872 vB14.2% lower feeOther transaction dataSignature data + group markerHypothetical sizes. Fee rate held constant.
Whole fee comparison, 10 inputs and 10 outputsHypothetical eligible inputs, default signing, no annex,34-byte output scripts. Geometry shows weight; labels show rounded vB. Same fee rate.02 / WHOLE TRANSACTIONSeparate1,016 vBHalf aggregate944 vB7.1% lower feeFull aggregate872 vB14.2% lower feeOther transaction dataSignature data + group markerHypothetical sizes. Fee rate held constant.
100 inputs, 1 output. Signature-heavy consolidation has a larger percentage fee benefit under these assumptions.
Whole fee comparison, 100 inputs and 1 outputsHypothetical eligible inputs, default signing, no annex,34-byte output scripts. Geometry shows weight; labels show rounded vB. Same fee rate.02 / WHOLE TRANSACTIONSeparate5,804 vBHalf aggregate5,012 vB13.6% lower feeFull aggregate4,220 vB27.3% lower feeOther transaction dataSignature data + group markerHypothetical sizes. Fee rate held constant.Full aggregate retains 65 bytes:64-byte signature + 1-byte group marker.
The input/output mix changes the fee benefit. These Draft proposals still require a soft fork and wallet support.
Hypothetical examples: all inputs eligible in one group, default sighashes, no annex, 34-byte output scripts. Blue includes the group marker in transaction panels; top section is signature payload alone. Not current network averages or available discounts. Activation parameters remain unset.
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.
