# Bitcoin (BTC) Signature Aggregation Drafts Could Cut Modeled Fees 27.3% By Simon Yoon Canonical URL: https://www.tokenpost.com/news/technology/54492 Published: 2026-11-11T21:26:19.000Z Updated: 2026-11-11T21:26:19.000Z Section: Technology > Three proposals entered the BIPs repository from Nov. 2-4. BIP 460 calls for a soft fork and leaves activation parameters for a future update. Three Bitcoin signature-aggregation drafts entered the proposal archive in early November, outlining formats that could shrink select transactions and lower modeled fees by as much as 27.3%. BIP 458 was merged Nov. 2, BIP 459 on Nov. 3 and BIP 460 on Nov. 4. They remain draft specifications; their addition to the repository did not change Bitcoin’s network rules or make lower fees available to users. BIP 458 describes 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 the methods across transaction inputs. The signature data alone shrinks substantially in a 10-signature example: from 640 bytes to 352 bytes with half-aggregation or 64 bytes with full aggregation. Those figures cover signature data, not the full transaction. A separate model estimates smaller changes in total transaction size. For a hypothetical transaction with 10 inputs and 10 outputs, the modeled size declines from 1,016 virtual bytes (vB) to 944 vB with half-aggregation or 872 vB with full aggregation. At the same fee rate, those sizes imply estimated fee reductions of 7.1% and 14.2%. For a hypothetical transaction consolidating 100 inputs into one output, the modeled size falls from 5,804 vB to 5,012 vB or 4,220 vB. At an unchanged fee rate, those changes imply estimated reductions of 13.6% and 27.3%. The examples assume all inputs are eligible and belong to one aggregation group, with default sighash settings, no annex and 34-byte output scripts. These scenarios do not represent typical transactions or a discount available today, and fees would still vary with the fee rate and transaction design. BIP 460 proposes using 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 would need to support the proposed output type before users could create or spend those outputs. The drafts follow a [BIP 460-based PISA prototype limited to regtest](). Full aggregation also brings a signing risk: BIP 459 warns that reusing secret nonces can expose a signer’s private key. BIP 460 calls for a soft fork and leaves activation parameters for a future update. The proposals provide no deployment schedule. ## Links in this article - [BIP 460-based PISA prototype limited to regtest](https://www.tokenpost.com/news/technology/39698)