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%.
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.
cryptoslate.com
