Bitcoin SegWit Savings Estimator: Witness Discount Fee Comparison

How the SegWit Witness Discount Reduces Bitcoin Fees

Segregated Witness (SegWit), activated at block 481,824 on August 24, 2017, introduced a witness discount that fundamentally changed how Bitcoin transaction fees are calculated. Instead of charging equally for all transaction data, SegWit splits a transaction into two parts: base data (inputs, outputs, metadata) and witness data (signatures, public keys). Base data costs 4 weight units per byte, while witness data costs just 1 weight unit per byte. This 75% discount on signature data translates directly into lower fees for anyone using SegWit addresses.

The fee you pay on Bitcoin is determined by your transaction's size in virtual bytes (vB) multiplied by the current fee rate in sat/vB. Because SegWit moves bulky signature data into the discounted witness section, your transaction's virtual size shrinks even though its raw byte count stays roughly the same. The formula is straightforward: vB = weight / 4, where weight = (non-witness bytes × 4) + (witness bytes × 1).

Transaction Size Comparison by Address Type

The following table compares a standard single-signature transaction with 1 input and 2 outputs (the most common pattern: one payment, one change) across all four major Bitcoin address types. Raw bytes represent the full serialized transaction size. Virtual bytes reflect the fee-relevant size after applying the witness discount.

For legacy P2PKH transactions, there is no witness data, so raw bytes and virtual bytes are identical. For P2WPKH, the ~107 bytes of signature and public key data are moved into the witness, where they cost only 1 WU per byte instead of 4. This is why a P2WPKH transaction is slightly smaller in raw bytes (222 vs 226) but dramatically smaller in virtual bytes (141 vs 226).

P2TR (Taproot) uses 64-byte Schnorr signatures instead of the 71-73 byte ECDSA signatures used by P2WPKH, making its inputs the smallest of any type at ~57.5 vB. However, P2TR outputs are 43 bytes (vs 31 for P2WPKH), so for output-heavy transactions P2WPKH remains more efficient. See our Taproot fee savings calculator for a detailed P2WPKH vs P2TR breakdown.

Input and Output Size Breakdown

The witness discount has its greatest impact on inputs because that's where signatures live. Each additional SegWit input saves roughly 80 vB compared to its legacy equivalent. The table below breaks down the per-component sizes that determine total transaction weight.

The savings compound with more inputs. A 5-input consolidation transaction costs ~750 vB with P2PKH but only ~370 vB with P2WPKH: a 50% reduction. This makes native SegWit especially valuable for UTXO consolidation during low-fee periods. Use our consolidation calculator to estimate savings for your specific UTXO set.

How the Weight Formula Works

BIP 141 replaced Bitcoin's 1 MB block size limit with a 4,000,000 weight unit block weight limit. The weight of a transaction is calculated as:

weight = base_size × 3 + total_size

This is mathematically equivalent to counting non-witness bytes at 4 WU each and witness bytes at 1 WU each. The formula uses base_size × 3 + total_size rather than non_witness × 4 + witness × 1 because it avoids the need to separate bytes into categories during serialization.

Virtual bytes convert weight back into a single fee-calculation unit: vB = ⌈weight / 4⌉. For legacy transactions, vB equals raw bytes exactly. For SegWit transactions, vB is always less than raw bytes because witness data is discounted. The fee estimation algorithm in Bitcoin Core uses vB as the standard unit for all fee rate calculations.

Why a single weighted metric? BIP 141's authors chose a single weight formula over dual limits (one for base data, one for witness data) because dual limits would create a complex non-linear optimization problem for miners constructing block templates. A single metric keeps the knapsack problem solvable with standard greedy algorithms.

Fee Savings at Different Fee Rates

The percentage savings from SegWit remain constant regardless of fee rate, but the absolute savings in satoshis scale linearly. During fee spikes, the dollar value of switching from legacy to native SegWit becomes substantial. The table below shows savings for a standard 1-input, 2-output transaction (226 vB legacy vs 141 vB native SegWit) at various fee rates.

Check the current Bitcoin fee estimator for live fee rate data. During congestion events, fee rates can exceed 500 sat/vB, making the SegWit discount worth $40+ per transaction.

Migration Path: Legacy to Native SegWit

Migrating from legacy addresses to native SegWit is straightforward but requires moving your funds. You cannot simply "upgrade" an existing P2PKH address to P2WPKH: they use different derivation paths (BIP 44 for P2PKH vs BIP 84 for P2WPKH) and different address encodings (Base58Check vs Bech32).

Steps for migration:

1. Generate a new native SegWit wallet (or switch your existing wallet to bc1q address generation)
2. Wait for a low-fee period to minimize transfer costs
3. Send your balance from the legacy address to your new bc1q address
4. Update any services or contacts that send to your old address

If you have many small UTXOs on legacy addresses, consider consolidating them in a single transaction during low-fee windows. You pay legacy rates for the migration transaction itself, but every subsequent spend benefits from the witness discount.

Wallet and Exchange Support

Native SegWit (bc1q) sending and receiving is universally supported across the Bitcoin ecosystem as of 2025. Bitcoin Core has defaulted to P2WPKH addresses since version 0.20.0.

Full native SegWit support:

• Software wallets: Bitcoin Core, Electrum, Sparrow, BlueWallet, Exodus, Trust Wallet
• Hardware wallets: Trezor, Ledger, BitBox02, Coldcard, Jade
• Exchanges: Coinbase, Kraken, Gemini, Bitstamp, River, Binance

Wrapped SegWit (P2SH-P2WPKH, 3... addresses) was a transitional format that allowed backward compatibility when some services couldn't send to bc1q addresses. Since bech32 support is now universal, there is no reason to use wrapped SegWit for new wallets. If you're still on wrapped SegWit, migrating to native SegWit saves an additional ~15% on fees compared to the wrapped format.

SegWit Adoption and Network Impact

Approximately 85-90% of all Bitcoin transactions now include at least one SegWit input, with P2WPKH accounting for the majority of transaction inputs. The SegWit adoption tracker shows the current breakdown by address type.

A study by Veriphi published through Bitcoin Optech analyzed transactions from SegWit activation through mid-2020 and estimated that universal native SegWit adoption could have saved approximately 37,000 BTC in fees during that period alone. Combined with transaction batching, total potential savings were estimated at 58,000 BTC, representing over 27% of all fees paid. With higher adoption rates and elevated fee environments since 2020, cumulative real savings are substantially larger.

The remaining 10-15% of legacy transactions come from services and wallets that have not upgraded since 2017. These users pay a consistent premium on every on-chain transaction. For high-volume services processing thousands of transactions daily, the difference between legacy and native SegWit fees amounts to significant operational costs.

SegWit vs Layer 2 Fee Savings

While SegWit reduces on-chain fees by ~38%, layer 2 solutions offer even larger savings for frequent transactions. The Lightning Network reduces per-payment costs to fractions of a satoshi for routed payments, though it requires channel management overhead. Solutions like Spark enable instant, near-zero-fee transfers on Bitcoin without the complexity of channel management, making them practical for high-frequency use cases where even SegWit-optimized on-chain fees are too high.

The optimal strategy combines both: use native SegWit for on-chain settlement and UTXO management, and layer 2 protocols for day-to-day payments. For a detailed comparison, see our research on Bitcoin fee market dynamics.

Frequently Asked Questions

How much do you save with SegWit vs legacy Bitcoin addresses?

A standard single-signature transaction (1 input, 2 outputs) costs ~226 vB with a legacy P2PKH address and ~141 vB with a native SegWit P2WPKH address: a savings of approximately 38%. At a fee rate of 50 sat/vB, that translates to 4,250 fewer satoshis per transaction. The savings percentage is consistent regardless of fee rate, but absolute savings grow during high-fee periods.

What is the witness discount in Bitcoin?

The witness discount is a pricing mechanism introduced by BIP 141 that charges witness data (signatures and public keys) at 1 weight unit per byte, while non-witness data costs 4 weight units per byte. This effectively gives witness data a 75% discount. The rationale is that witness data is less costly for nodes to process and store compared to UTXO-affecting data, and the discount incentivizes more efficient transaction formats.

Should I use P2WPKH or P2TR for the lowest fees?

It depends on the transaction pattern. P2WPKH has smaller outputs (31 bytes vs 43 bytes for P2TR), making it cheaper for transactions with many outputs. P2TR has smaller inputs (~57.5 vB vs ~68 vB for P2WPKH), making it cheaper for input-heavy transactions like UTXO consolidations. For the most common pattern (1 input, 2 outputs), P2WPKH is slightly cheaper at ~141 vB vs ~155 vB. See our address type fee savings comparison for more scenarios.

Is it worth migrating from wrapped SegWit to native SegWit?

Yes. Wrapped SegWit (P2SH-P2WPKH, starting with 3...) uses ~166 vB per standard transaction compared to ~141 vB for native SegWit (P2WPKH, starting with bc1q). That's an additional ~15% savings. Since all major wallets and exchanges now support bech32 addresses, there is no compatibility reason to stay on wrapped SegWit. Wait for a low-fee period, then send your funds to a new bc1q address.

How are virtual bytes calculated?

Virtual bytes are calculated by dividing the transaction's weight by 4 (rounded up). Weight is computed as base_size × 3 + total_size, where base_size is the transaction without witness data and total_size is the full serialized transaction. For legacy transactions with no witness data, vB equals raw bytes. For SegWit transactions, vB is always less than raw bytes.

Why did Bitcoin add the witness discount instead of just increasing the block size?

The witness discount was part of the SegWit soft fork, which was backward-compatible: non-upgraded nodes could still validate blocks without understanding witness data. A raw block size increase would have required a hard fork, splitting the network if not all nodes upgraded. The 4 million WU limit effectively increased capacity to approximately 2-2.3 MB of actual block data while maintaining backward compatibility, fixing transaction malleability, and incentivizing the adoption of more efficient transaction formats.

Do SegWit savings apply to multisig transactions?

Yes, and the savings are even larger for multisig transactions because they contain more signature data. A 2-of-3 P2WSH multisig transaction moves multiple signatures and the redeem script into the witness, saving approximately 45-50% compared to the equivalent legacy P2SH multisig. For even greater efficiency, MuSig2 key aggregation produces a single 64-byte Schnorr signature regardless of the number of signers.

This tool is for informational purposes only and does not constitute financial advice. Transaction sizes are approximate and may vary slightly based on signature length, number of witness items, and wallet implementation. Fee rates fluctuate continuously. Always verify current fee conditions before broadcasting transactions.