Bitcoin's BIP repository merges drafts BIP458-BIP460 for signature aggregation
In brief
- BIP458, BIP459 and BIP460 were merged into Bitcoin's proposal repository Nov. 2-4, per CryptoSlate.
- Input signatures are combined under the drafts via either half-aggregation or full aggregation.
- Fee cuts of about 7.1% to 27.3% appear in CryptoSlate's hypothetical transaction models.
- Activation parameters aren't set; a soft fork and wallet support are still required.
Two ways to shrink signatures
BIP458 was merged on Nov. 2, BIP459 on Nov. 3 and BIP460 on Nov. 4, CryptoSlate reported. All three work by combining the signatures attached to transaction inputs (the coins being spent).
There are two versions. Half-aggregation combines signatures that were produced independently, with no interactive signing session, and turns n 64-byte signatures into 32(n+1) bytes. Full aggregation requires coordinated signing but produces a single 64-byte signature for the whole group. With ten signatures, that means 640 bytes shrinking to 352 bytes (45%) or to 64 bytes (90%), before encoding overhead.
That's just the signature payload, though. CryptoSlate noted that the cut to a whole transaction's fee would be much smaller.
What the fee math looks like
Bitcoin fees are usually quoted per virtual byte (vB). Virtual size is transaction weight divided by four, rounded up. CryptoSlate ran its own calculations on two hypothetical transactions using BIP460 witness forms and BIP141/144 encoding. They aren't current network averages, and they aren't discounts anyone can get today.
In the first model, a joint payment with ten inputs and ten outputs shrank from 1,016 vB to 944 vB with half-aggregation or 872 vB with full aggregation. That's a fee cut of about 7.1% or 14.2%. At an illustrative 10 satoshis per vB, it works out to 720 or 1,440 satoshis saved.
In the second, consolidating 100 inputs into one output cut size from 5,804 vB to 5,012 vB (half) or 4,220 vB (full), which lowered fees by roughly 13.6% or 27.3%. Both models assumed that every input sat in one eligible aggregation group, with default signing settings, 34-byte output scripts and no annex.
Under those assumptions, the signature-heavy consolidation gets the bigger percentage benefit.
Activation and wallets are unresolved
BIP460 leaves activation parameters unspecified. Its proposed witness version (currently v2) also needs coordination with other proposals.
Existing Taproot outputs won't gain aggregation automatically. Wallets would need to support a new output type, and aggregation only covers key-path spends. Script-path spends can't join aggregation groups, and eligible inputs can opt out.
Signing is a hurdle of its own. Full aggregation needs a stateful two-round protocol, and reusing secret nonces can expose signing keys. That makes support on hardware and air-gapped devices demanding. Half-aggregation skips the joint signing session, but building a transaction together still requires the parties to agree.
Frequently asked questions
What is the difference between half-aggregation and full aggregation?
Half-aggregation combines signatures that were produced independently, with no interactive signing session, and turns n 64-byte signatures into 32(n+1) bytes. Full aggregation requires coordinated signing but produces a single 64-byte signature for every aggregated signature in a group.
How much would signature aggregation lower Bitcoin transaction fees?
CryptoSlate calculated fee cuts of about 7.1% or 14.2% for a hypothetical ten-input, ten-output joint payment. For a hypothetical 100-input consolidation, the cuts were about 13.6% or 27.3%. These are modeled figures, not network averages or discounts available today.
Are BIP458, BIP459 and BIP460 active on Bitcoin?
No. They're draft proposals that still require a soft fork and wallet support. BIP460 leaves activation parameters unspecified, and its proposed witness version needs coordination with other proposals.
