Bitcoin Signature Drafts Model 27.3% Lower Fees, Not Yet Live

By Elena Vasquez

A model accompanying three Bitcoin improvement proposals estimates fee reductions of up to 27.3% for a transaction consolidating 100 inputs into one output, but the Nov. 2-4 submissions changed no network rules and deliver no savings today.

The BIPs repository merged BIP 458 on Nov. 2, BIP 459 on Nov. 3 and BIP 460 on Nov. 4. All three remain draft specifications. Repository inclusion records a proposal, not protocol activation, so the estimates describe future technical possibilities rather than a deployed fee feature.

What do the three drafts change?

• BIP 458 defines noninteractive half-aggregation, which combines signatures without requiring signers to coordinate in a joint signing session.
• BIP 459 specifies full aggregation, which can combine signatures into one 64-byte signature but requires signers to coordinate through two rounds.
• BIP 460 proposes applying those methods across transaction inputs.

In a 10-signature example, half-aggregation reduces signature data from 640 bytes to 352 bytes, while full aggregation reduces it to 64 bytes. Those figures isolate signatures rather than full transaction size and therefore do not equal fee reductions. The practical point is that the drafts could remove signature overhead, but user savings depend on the rest of each transaction.

How large are the modeled fee reductions?

A separate model examines two hypothetical transaction structures:

• A transaction with 10 inputs and 10 outputs falls from 1,016 virtual bytes (vB) to 944 vB with half-aggregation or 872 vB with full aggregation. At the same fee rate, those changes imply estimated fee reductions of 7.1% and 14.2%, respectively.
• A transaction consolidating 100 inputs into one output falls from 5,804 vB to 5,012 vB with half-aggregation or 4,220 vB with full aggregation. At the same fee rate, the estimated reductions are 13.6% and 27.3%.

These examples require every input to be eligible and to belong to one aggregation group. They also assume default sighash settings, no annex and 34-byte output scripts.

The model does not represent typical transactions, and fees would still vary with the selected fee rate and transaction design. The practical point is that 27.3% is a conditional estimate, not a general discount or an immediate market forecast.

What must happen before users see savings?

BIP 460 would apply aggregation across transaction inputs through a new SegWit witness version for Taproot-style key-path spends. It excludes script-path spends, and existing Taproot outputs would not gain aggregation automatically. Wallets must support the proposed output type before users can create or spend those outputs.

Full aggregation adds a cryptographic operating risk. BIP 459 warns: “reusing secret nonces can expose a signer’s private key.” The drafts follow a BIP 460-based PISA prototype limited to regtest, leaving the referenced implementation confined to that test environment.

BIP 460 calls for a soft fork and leaves activation parameters for a future update. None of the proposals provides a deployment schedule. The practical point is that adoption requires a consensus-rule change, specified activation and wallet implementation, while full aggregation also requires safe nonce handling.

The next verifiable checkpoint is the future BIP 460 update that sets activation parameters. Until that update is followed by supporting wallet releases and a public deployment, the modeled 27.3% reduction remains a draft-stage estimate rather than an available fee reduction.