0x3e80c27a3e80…3e80c277
BIP 460 Models a 27.3% Fee Cut, but Activation Is Undefined
BIP 460 models a 27.3% fee cut for a 100-input Bitcoin consolidation, but draft status, unspecified soft-fork terms and wallet limits narrow the practical case.

Outputs
BIP 460 models a 27.3% fee reduction for a 100-input consolidation, from 5,804 to 4,220 virtual bytes.
For ten inputs and ten outputs, modeled fee reductions are 7.1% with half-aggregation and 14.2% with full aggregation.
Ten signatures shrink from 640 bytes to 352 bytes with BIP 458 or 64 bytes with BIP 459.
BIP 460 requires wallet support for witness-v2 outputs, though inputs may initially use standard BIP 341 signatures.
BIP 460 remains a draft with unspecified soft-fork parameters and depends on BIPs 340, 341, 458 and 459.
A modeled 100-input Bitcoin consolidation using the full-aggregation option in draft BIP 460 falls from 5,804 to 4,220 virtual bytes, producing a modeled 27.3% fee reduction.
That result applies to one favorable construction, not Bitcoin transactions generally. BIP 460 remains a draft, its soft-fork activation parameters remain unspecified, and the proposal permits wallets to support witness-v2 outputs without immediately implementing signature aggregation.
What does BIP 460 change?
BIP 460 describes cross-input aggregation and Taproot-style key-path spending under witness version 2. It depends on BIPs 340, 341, 458, and 459, making it an extension of existing signature and spending rules rather than a standalone transaction format.
BIP 458 provides half-aggregation: signers do not coordinate, and n 64-byte signatures become 32(n+1) bytes. BIP 459 provides full aggregation, which requires signers to work together and represents a group with one 64-byte signature.
For ten signatures, the payload falls from 640 bytes to 352 bytes under half-aggregation, a 45% reduction, or to 64 bytes under full aggregation, a 90% reduction. Those figures concern signatures alone; they do not describe an equivalent reduction in the complete transaction.
That distinction keeps the headline percentage in check. Signatures occupy only part of a transaction, so large signature savings translate into smaller savings across virtual bytes and fees.
How much would fees actually fall?
The proposal's modeled transactions separate payload gains from total transaction economics:
- Ten inputs and ten outputs: Modeled size falls from 1,016 virtual bytes to 944 with half-aggregation and 872 with full aggregation. The model reports fee reductions of 7.1% and 14.2%, respectively.
- A 100-input consolidation into one output: Modeled size falls from 5,804 virtual bytes to 5,012 under half-aggregation and 4,220 under full aggregation. The modeled fee reductions reach 13.6% and 27.3%.
On a dollar-denominated fee, the 27.3% modeled reduction removes roughly 27 cents for every dollar charged, provided the fee rate remains constant.
The larger case shows where aggregation has operational value: many eligible signatures make up more of the transaction, reducing the byte weight that drives fee calculation. The smaller case shows why a 90% signature-payload reduction cannot be presented as a 90% fee reduction.
What must happen before users can benefit?
The proposal calls for activation "through a soft fork," but it does not specify the parameters, and the material provides no activation date. Wallets must also recognize and support the proposed witness-v2 outputs before users can create and spend them.
The material names no wallet vendors and offers no implementation schedule.
The rollout does not require an all-at-once switch. BIP 460 lets inputs "opt out of aggregation" and use standard BIP 341 signatures, so a wallet can support the new witness version without implementing signature aggregation immediately.
That separation lowers the coordination burden for wallet developers, but it also limits early savings. Users receive the fee benefit only when their inputs qualify for aggregation and participating wallets actually use it.
Why is 27.3% not a general estimate?
The model assumes that every input belongs to one eligible aggregation group. It also assumes default signing settings, 34-byte output scripts, and no annex or extra witness data. These assumptions create a clean transaction that may not resemble many real Bitcoin transfers.
BIP 460 excludes script-path signatures from aggregation. It also permits opt-outs when a protocol requires a particular signature to appear on-chain. Transactions with fewer eligible inputs, different spending paths, or more non-signature data would not reach the modeled 27.3% reduction.
A related Bitcoin quantum-risk report cited in the material says 7.12 million BTC have visible public keys. That figure addresses key exposure rather than fee performance, and the proposal material offers no quantum-resistance assessment for these signature schemes.
The next structural checkpoint is a fully parameterized soft fork; until that activation and compatible wallet support exist, the modeled 27.3% savings remain unavailable.
via cryptonews.net (Source)
More from Elena Vasquez
Show full bio
Staff writer covering regulation, policy and their impact on crypto and web3 industry at Mempool Brief.
945 articles