Bitcoin devs merge 3 new BIPs, and transaction fees could plummet

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

Choose a hypothetical transaction

10 inputs, 10 outputs. Many outputs leave less of the transaction available for signature compression.

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.

Sources and evidence

Sources

1. BIP460
2. BIP458
3. BIP459
4. BIP141
5. BIP144
6. BIP460 review and merge record

Supporting facts

• For ten signatures, the schemes reduce the 640-byte signature payload to 352 bytes with half-aggregation or 64 bytes with full-aggregation, reductions of 45% and 90% before transaction encoding overhead. [2] [3]
• BIP460 leaves soft-fork activation parameters unspecified, and the proposed witness version is subject to coordination with other proposals. [1] [6]
• The proposed integration keeps witness-stack framing, adds one marker byte per aggregation group and allows inputs to opt out with ordinary BIP341 signatures; opted-out spends cannot join an aggregate. [1]
• Bitcoin virtual size is transaction weight divided by four, rounded up; signature bytes are witness data, so signature-payload reductions do not equal percentage reductions in total transaction fees. [4] [5] [1]
• In a hypothetical ten-input, ten-output joint transaction with all inputs eligible, default sighashes, no annex and 34-byte witness-program outputs, half-aggregation reduces rounded size from 1,016 to 944 vB and full-aggregation to 872 vB: approximately 7.1% and 14.2% lower fees at an unchanged fee rate. [1] [4] [5]
• In a hypothetical 100-input consolidation with all inputs eligible, default sighashes, no annex and one 34-byte witness-program output, half-aggregation reduces rounded size from 5,804 to 5,012 vB and full-aggregation to 4,220 vB: approximately 13.6% and 27.3% lower fees at an unchanged fee rate. [1] [4] [5]

Method

Original calculations from BIP460 witness forms and BIP141/144 encoding. Base=10+41n+43m bytes; W0=4B+2+66n, Wh=4B+2+2n+32(n+1)+1, Wf=4B+2+2n+65. vB=ceil(W/4). Bars scale by weight; labels are rounded vB. Fee savings=(v0-v)/v0 at a fixed rate, rounded to 0.1%.

Scope

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.

Infographic by CryptoSlate

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.