Three draft Bitcoin proposals explain how signature aggregation could lower fees for some transactions. In a modeled example, combining 100 inputs into one output reduces the transaction’s size enough to cut fees by 27.3% with full aggregation.
That figure applies only if the inputs meet the proposal’s conditions, and the change is not yet active. The rules would first have to be activated through a soft fork, and wallets would need to support the new transaction format.
Why 100 Inputs Produce the Biggest Modeled Savings
Bitcoin fees are calculated using a transaction’s virtual size, which is derived from its weight under BIP 141. Signature aggregation reduces the amount of signature data and can therefore shrink transaction size. Since other transaction data also adds to the size, the fee reduction is smaller than the drop in signature bytes.
BIP 458 outlines half-aggregation, which combines signatures without requiring signers to coordinate. It reduces n 64-byte signatures to 32(n+1) bytes. BIP 459 outlines full aggregation. Although this approach requires signers to work together, it can encode a group’s signatures as one 64-byte signature.
With ten signatures, the signature payload would fall from 640 bytes to 352 bytes under half-aggregation, or 64 bytes under full aggregation. That amounts to payload reductions of 45% and 90%, respectively. The whole transaction would not shrink by those same percentages, because signatures account for only part of its total size.
The modeled transactions illustrate the effect on fees. A transaction with ten inputs and ten outputs shrinks from 1,016 virtual bytes to 944 with half-aggregation, or 872 with full aggregation. The corresponding fee reductions are 7.1% and 14.2%.
In comparison, consolidating 100 inputs into one output cuts virtual size from 5,804 to 5,012 or 4,220, resulting in larger reductions of 13.6% or 27.3%.
Follow us on X for real-time crypto updates.
A Soft Fork and Wallet Upgrades Must Come First
BIP 460, a proposal for cross-input aggregation, is labeled a draft. It describes Taproot-style key-path spending under witness version 2 and relies on BIPs 340, 341, 458, and 459. The proposal specifies activation through a soft fork, but does not yet specify activation parameters.
Wallet support would be required as well. Wallets would have to recognize and support the proposed witness-v2 outputs to create and spend them. However, BIP 460 lets inputs opt out of aggregation and use standard BIP 341 signatures. This means wallets could support the new witness version without immediately implementing signature aggregation.
Why the 27.3% Figure Has Limits
The model assumes every input belongs to the same eligible aggregation group. It also assumes default signing settings and 34-byte output scripts, with no annex or additional witness data.
BIP 460 does not allow script-path signatures to be aggregated, and some inputs may opt out if a protocol requires a particular signature to appear on-chain. As a result, transactions with fewer eligible inputs, different spending paths, or more non-signature data would not see the modeled 27.3% reduction.
Related: Bitcoin Quantum Risk Rises as 7.12M BTC Have Visible Public Keys
Add A Comment
Comments are closed.