Bitcoin Signature Upgrade Could Cut Fees by 27.3%

Three draft Bitcoin proposals describe signature aggregation methods that could reduce fees. A modeled 100-input consolidation showed a 27.3% cut with full aggregation, but the feature is not active.

Three draft Bitcoin proposals describe ways to reduce the signature data included in transactions. In a modeled example, consolidating 100 inputs into one output reduced the transaction’s virtual size enough to cut fees by 27.3% with full aggregation.

The proposals have not been activated. The rules would require approval through a Bitcoin soft fork, and wallets would need to support a proposed witness-v2 transaction format.

Bitcoin fees are based on a transaction’s virtual size, which is calculated from its weight under BIP 141. Reducing signature data can reduce that size, although inputs, outputs and other transaction data remain unchanged. The fee reduction therefore depends on how much of a transaction consists of signatures and how many inputs qualify for aggregation.

BIP 458 proposes half-aggregation, which combines signatures without requiring signers to coordinate. It would reduce n 64-byte signatures to 32(n+1) bytes. BIP 459 proposes full aggregation, which requires signers to coordinate and represents a group of signatures with one 64-byte signature.

For 10 signatures, the signature data would fall from 640 bytes to 352 bytes with half-aggregation and to 64 bytes with full aggregation. A transaction with 10 inputs and 10 outputs would shrink from 1,016 virtual bytes to 944 bytes with half-aggregation or 872 bytes with full aggregation. Those changes correspond to modeled fee reductions of 7.1% and 14.2%.

A 100-input consolidation into one output would shrink from 5,804 virtual bytes to 5,012 bytes with half-aggregation or 4,220 bytes with full aggregation. The modeled fee reductions would be 13.6% and 27.3%, respectively.

BIP 460, which proposes cross-input signature aggregation, remains a draft. It describes Taproot-style key-path spending under witness version 2 and depends on BIPs 340, 341, 458 and 459. Its activation parameters have not been specified.

Wallets would need to recognize witness-v2 outputs to create and spend them. BIP 460 would allow individual inputs to opt out of aggregation and use standard BIP 341 signatures, so wallets could support the new witness version without immediately adding aggregation support.

The 27.3% estimate applies only to the modeled conditions. It assumes that all 100 inputs belong to one eligible aggregation group, uses default signing settings and 34-byte output scripts, and excludes annex or additional witness data. Script-path signatures would not be aggregated, and some inputs could opt out when a transaction requires a particular signature to appear on-chain.

Reviewed and fact-checked by Alex Panasenko on November 11.

The material on GNcrypto is intended solely for informational use and must not be regarded as financial advice. We make every effort to keep the content accurate and current, but we cannot warrant its precision, completeness, or reliability. GNcrypto does not take responsibility for any mistakes, omissions, or financial losses resulting from reliance on this information. Any actions you take based on this content are done at your own risk. Always conduct independent research and seek guidance from a qualified specialist. For further details, please review our Terms, Privacy Policy and Disclaimers.

Articles by this author