On Nov. 2-4, Bitcoin’s proposal repository added three draft specifications that could reduce fees for payments jointly assembled by multiple users and for consolidating many inputs into a single output.
BIP458 was merged on Nov. 2, BIP459 on Nov. 3, and BIP460 on Nov. 4. The proposed mechanism combines the signatures associated with transaction inputs—the coins being spent.
Half-aggregation combines signatures produced independently, without an interactive signing session: n signatures of 64 bytes shrink to 32(n+1) bytes. Full aggregation requires coordinated signing, but yields one 64-byte signature for all signatures in a group.
For ten signatures, the size drops from 640 bytes to 352 or 64 bytes, respectively. That represents a 45% or 90% reduction in the signature payload before encoding overhead; the reduction in the fee for the entire transaction would be much smaller.
Reducing Bitcoin transaction fees
Bitcoin fees are commonly quoted per virtual byte (vB). Under Bitcoin’s weight rules, virtual size is transaction weight divided by four and rounded up.
The hypothetical examples place all inputs in a single eligible aggregation group and assume default signing settings, 34-byte output scripts, and no optional additional witness data, or annex. They include transaction overhead, witness encoding, and the group’s marker byte.
A joint transaction with ten inputs and ten outputs would drop from 1,016 vB to 944 vB with half-aggregation or 872 vB with full aggregation, reducing its fee by about 7.1% or 14.2%. At an illustrative rate of 10 satoshis per vB, the savings would be 720 or 1,440 satoshis.
The second example, consolidating 100 inputs into one output, benefits more. Its size declines from 5,804 vB to 5,012 vB with half-aggregation or 4,220 vB with full aggregation, cutting fees by approximately 13.6% or 27.3%.
BIP460 does not specify activation parameters. Its proposed witness version, currently v2, would require coordination with other proposals.
Wallets would have to support the new output type. Existing Taproot outputs would not automatically gain aggregation, which is restricted to direct signature-based or key-path spends.
Script-path spends, which execute scripts, cannot participate in aggregation groups; eligible inputs can also opt out.
Full aggregation requires a stateful, two-round signing protocol. Reusing secret nonces can expose signing keys, making support for hardware and air-gapped devices demanding. Half-aggregation avoids a joint signing session, though collaborative transaction construction still requires agreement.
Source: cryptoslate.com. Adapted by NBTC.
Add A Comment
Comments are closed.