Multiple Bitcoin signature paths combining into one verified transaction path

Three New Bitcoin Proposals Could Cut Some Transaction Fees by Up to 27%

• November 10, 2026 7:18 pm • Comments

Three newly published Bitcoin proposals could make certain transactions meaningfully smaller, but nobody should confuse a promising design with a fee cut that is available today.

CryptoSlate’s technical analysis reports that BIPs 458, 459 and 460 were merged into Bitcoin’s proposal repository on November 2, 3 and 4. Together, the drafts describe ways to aggregate Schnorr signatures attached to multiple transaction inputs.

The basic idea is simple: signatures take up space, and Bitcoin users pay fees based on transaction size. If several signatures can be represented more compactly, some multi-input transactions could cost less at the same fee rate.

BIP 458 covers half aggregation, which can combine independently produced signatures without requiring every signer to participate in one coordinated signing session. BIP 459 describes full aggregation, while BIP 460 lays out how cross-input signature aggregation could work with Taproot key-path spends.

The difference can be substantial at the signature level. Ten ordinary 64-byte signatures consume 640 bytes; the modeled half-aggregation design cuts that to 352 bytes, while full aggregation reduces it to a single 64-byte signature.

That does not translate into a 90% discount on the entire transaction. Inputs, outputs and other transaction data still consume space.

In one modeled 10-input, 10-output joint payment, CryptoSlate calculated that virtual size would fall from 1,016 vB to 944 vB with half aggregation or 872 vB with full aggregation. That works out to fee reductions of roughly 7.1% and 14.2% at an unchanged fee rate.

The modeled benefit was larger for a 100-input consolidation into one output. Virtual size fell from 5,804 vB to 5,012 vB under half aggregation and 4,220 vB under full aggregation, reductions of about 13.6% and 27.3%.

There are real tradeoffs. Full aggregation requires coordinated, stateful signing, and mishandling secret nonces can expose keys.

Wallets and hardware devices would need to support the proposed output type, while alternative Taproot spending paths would not participate in the same aggregation groups.

Most importantly, these are draft specifications. BIP 460 leaves activation parameters unset, and the package would require broader engineering review, wallet support and a Bitcoin network rule change before users could receive any benefit.

Still, this is the kind of Bitcoin development that matters. It does not promise a flashy new token or a quick price catalyst; it targets the cost and efficiency of using the network itself.

If the designs survive review and eventually activate, high-input consolidations and collaborative payments could become noticeably cheaper. Until then, the honest headline is potential: the engineering path is now public, but the savings are not live.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.