Three draft Bitcoin proposals describe how signature aggregation could reduce fees for some transactions. In a modeled example, consolidating 100 inputs into a single output reduces transaction size enough to lower fees by 27.3% under full aggregation.
That figure applies only when the inputs meet the proposal’s conditions; however, the change is not active. The rules would first need to be activated through a soft fork, and wallets would need to support the new transaction format.
Bitcoin fees are based on a transaction’s virtual size, which is calculated from its weight under BIP 141. Because signature aggregation reduces the amount of signature data, it can also reduce transaction size. Other transaction data still contributes to its size, so the fee reduction is smaller than the reduction in signature bytes.
BIP 458 describes half-aggregation, which combines signatures without requiring signers to coordinate. It reduces n 64-byte signatures to 32(n+1) bytes. BIP 459 describes full aggregation. This method requires signers to work together, but it can represent a group’s signatures with a single 64-byte signature.
For ten signatures, the signature payload would shrink from 640 bytes to 352 bytes with half-aggregation or 64 bytes with full aggregation. Those changes reduce the payload by 45% and 90%, respectively. They do not reduce the entire transaction by the same percentages since signatures make up only part of its total size.
The modeled transactions show how that difference affects fees. A transaction with ten inputs and ten outputs reduces from 1,016 virtual bytes to 944 with half-aggregation, or to 872 with full aggregation. Those size reductions translate into fee cuts of 7.1% and 14.2%.
By comparison, a 100-input consolidation into one output reduces the virtual bytes from 5,804 to 5,012 or 4,220, yielding larger reductions of 13.6% or 27.3%.
BIP 460, which proposes cross-input aggregation, is marked as a draft. It describes Taproot-style key-path spending under witness version 2 and depends on BIPs 340, 341, 458, and 459. The proposal calls for activation through a soft fork, but its activation parameters remain unspecified.
Wallet support would also be necessary. Wallets would need to recognize and support the proposed witness-v2 outputs to create and spend them. However, BIP 460 allows inputs to opt out of aggregation and use standard BIP 341 signatures, meaning wallets could support the new witness version without implementing signature aggregation immediately.
(adsbygoogle = window.adsbygoogle || []).push({});The model assumes that all inputs belong to a single eligible aggregation group. It also uses default signing settings and 34-byte output scripts, with no annex or extra witness data.
BIP 460 excludes script-path signatures from aggregation, and some inputs may opt out when a protocol needs a particular signature to appear on-chain. Therefore, transactions with fewer eligible inputs, different spending paths, or more non-signature data would not match the modeled 27.3% reduction.
