SegWit (Segregated Witness)

What Is SegWit?

Segregated Witness (SegWit) is a Bitcoin protocol upgrade activated in August 2017 via BIP 141. It restructures how transaction data is organized by moving signature (witness) data into a separate structure outside the traditional transaction format. This separation fixes a long-standing issue called transaction malleability while simultaneously increasing the effective block capacity.

Before SegWit, the signature data was included inside the transaction hash calculation. Anyone relaying a transaction could subtly alter the signature without invalidating it, which changed the transaction ID (txid). This made it unreliable to reference unconfirmed transactions by their txid: a critical requirement for protocols like Lightning that chain multiple unconfirmed transactions together.

SegWit was deployed as a soft fork, meaning it was backward-compatible with older nodes. Non-upgraded nodes still see SegWit transactions as valid, though they cannot fully validate the witness data. This design allowed the network to upgrade incrementally without a disruptive chain split.

How It Works

SegWit modifies the transaction serialization format by splitting data into two parts: the base transaction (inputs, outputs, version, locktime) and the witness (signatures, redeem scripts). The witness is committed to the block via a new commitment in the coinbase transaction, but it lives outside the traditional block structure that legacy nodes parse.

Transaction Malleability Fix

In pre-SegWit transactions, the scriptSig (which contains the signature) is included in the data that gets hashed to produce the txid. Because ECDSA signatures have multiple valid encodings for the same key and message, a third party could modify the signature encoding and change the txid without invalidating the transaction. This is the malleability problem.

SegWit fixes this by removing the signature from the txid calculation entirely. The witness data is committed separately via a witness txid (wtxid). The base txid now depends only on inputs, outputs, version, and locktime: fields that cannot be altered without the private key. This makes txids stable and reliable for referencing in unconfirmed transaction chains, which is foundational for payment channels and the Lightning Network.

Weight Units and Block Limits

SegWit replaces the 1 MB block size limit with a 4,000,000 weight unit (4 MWU) limit. Each byte of base transaction data counts as 4 weight units, while each byte of witness data counts as 1 weight unit. This discount reflects the lower cost of witness data to the network: nodes that do not fully validate can prune witness data, and it only needs to be transmitted once.

# Weight calculation
base_size = size of transaction without witness data
total_size = size of transaction with witness data
witness_size = total_size - base_size

weight = (base_size * 4) + witness_size
virtual_size = weight / 4  # vbytes, used for fee calculation

# Example: a typical P2WPKH transaction
# base_size = 82 bytes, witness_size = 109 bytes
# weight = (82 * 4) + 109 = 437 weight units
# virtual_size = 437 / 4 = 109.25 vbytes

Because fee rates are calculated per virtual byte (vbyte), SegWit transactions pay lower fees than equivalent legacy transactions. A typical single-input, single-output P2WPKH transaction uses roughly 109 vbytes compared to 192 bytes for the equivalent legacy P2PKH transaction: a fee reduction of over 40%. For more on how fees interact with block space, see the Bitcoin fee market dynamics research article.

Address Types

SegWit introduced several new address formats, each serving different use cases:

• P2WPKH (Pay-to-Witness-Public-Key-Hash): the standard SegWit address for single-key wallets. Uses bech32 encoding, starting with bc1q. Provides the full fee discount and is the most common SegWit address type.
• P2WSH (Pay-to-Witness-Script-Hash): the SegWit equivalent of P2SH, used for multisig and complex scripts. Also uses bech32 encoding with a bc1q prefix but with a longer address (62 characters vs 42 for P2WPKH).
• P2SH-P2WPKH (nested/wrapped SegWit): wraps a SegWit output inside a P2SH script for backward compatibility with wallets that cannot send to native bech32 addresses. Uses the standard 3 prefix. Fees are lower than legacy but higher than native SegWit because the P2SH wrapper adds overhead.
• P2SH-P2WSH (nested/wrapped SegWit script): the wrapped variant for multisig, combining P2WSH inside P2SH. Used when counterparties cannot handle native bech32 addresses.

# Address format comparison
Legacy P2PKH:     1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Nested P2SH:      3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Native P2WPKH:    bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
Native P2WSH:     bc1qrp33g0q5b5698ahp5jnf5yzjmgcea8...
Taproot P2TR:     bc1p5cyxnuxmeuwuvkwfem96lqzszee2...

The Taproot upgrade (activated November 2021) extends the witness versioning system by introducing version 1 witness programs (v0 is SegWit). Taproot addresses use bech32m encoding and the bc1p prefix. For a detailed look at what Taproot adds, see the Taproot and Schnorr signatures research article.

Witness Versioning

One of SegWit's most important design decisions is the witness version byte. Every SegWit output begins with a version number (0 for the original SegWit, 1 for Taproot). This makes future upgrades possible through soft forks: new witness versions can define entirely new validation rules without breaking compatibility with existing nodes.

Versions 2 through 16 are reserved for future upgrades. This extensible design means SegWit is not just a one-time fix but a framework for ongoing Bitcoin development. Proposals like eltoo and new scripting capabilities can be deployed via new witness versions without requiring hard forks.

Use Cases

Enabling Lightning Network

SegWit's malleability fix was the primary prerequisite for the Lightning Network. Lightning channels are built by creating a funding transaction on-chain and then exchanging pre-signed commitment transactions that spend from it. If the funding transaction's txid could be altered (malleated), all commitment transactions referencing that txid would become invalid, and channel funds could be lost.

With SegWit, the funding txid is immutable, making it safe to build chains of unconfirmed transactions. Lightning channels, HTLCs, anchor outputs, and protocols like splicing all depend on this guarantee. Without SegWit, the Lightning Network as it exists today would not be possible.

Fee Savings for Wallets and Exchanges

The witness discount directly reduces transaction fees. For entities processing large volumes of transactions (exchanges, payment processors, custodians), migrating to native SegWit addresses yields significant cost savings. A typical P2WPKH spend saves roughly 40% on fees compared to legacy P2PKH, and multisig P2WSH transactions can save even more due to the larger witness data in multi-signature setups.

Fee savings compound with techniques like transaction batching. When an exchange batches hundreds of withdrawals into a single SegWit transaction, the per-withdrawal cost drops substantially. This efficiency benefits the entire network by reducing overall block space demand.

Improved UTXO Efficiency

Because witness data is discounted, SegWit transactions are more efficient in how they consume UTXO set resources. The UTXO model requires every unspent output to be tracked by full nodes. SegWit's weight system encourages spending patterns that minimize UTXO set growth, since outputs (which add to the UTXO set) are counted at full weight while witnesses (which don't persist in the UTXO set) are discounted.

Partially Signed Bitcoin Transactions

SegWit's clean separation of witness data makes it significantly easier to construct PSBTs (Partially Signed Bitcoin Transactions). In the legacy format, determining the correct sighash for signing required access to the full previous transaction for each input. SegWit's new signing algorithm (BIP 143) only requires the value of the input being spent, simplifying signing for hardware wallets, multisig coordinators, and offline signing workflows.

Adoption and Metrics

SegWit adoption has grown steadily since activation. As of early 2026, native SegWit and Taproot transactions account for over 80% of all Bitcoin transactions. Major wallets, exchanges, and services have migrated to native SegWit (bech32) as their default address format.

The transition from wrapped (P2SH-nested) to native SegWit was gradual. Early adoption relied heavily on wrapped addresses because many services could not send to bech32 addresses. As bech32 support became universal, the ecosystem shifted to native formats for maximum fee savings. The pattern is repeating with Taproot (bech32m) adoption, which is following a similar growth curve.

Risks and Considerations

Anyone-Can-Spend Perception

To maintain backward compatibility, SegWit outputs appear as "anyone can spend" to pre-SegWit nodes. These older nodes see SegWit outputs as having no spending conditions and consider any transaction spending them as valid. In reality, upgraded nodes enforce the SegWit rules, so this is only a concern if a majority of mining hashrate reverted to pre-SegWit software: an extremely unlikely scenario given widespread adoption.

Legacy Compatibility

Some older wallets and services still cannot send to native bech32 addresses. Users occasionally need to use wrapped (P2SH-nested) SegWit addresses to receive funds from legacy systems, sacrificing some fee savings. This issue has diminished over time but has not been fully eliminated.

Witness Data Pruning Implications

The weight discount assumes that witness data is less costly to the network because it can be pruned after validation. However, during initial block download and full validation, all witness data must still be transmitted and verified. Blocks that are close to the 4 MWU limit with large witness payloads can be slower to propagate than pre-SegWit blocks, though this has not been a significant issue in practice.

Incomplete Adoption

While the majority of transactions now use SegWit, a portion of the network still generates legacy transactions. This means the theoretical maximum block capacity (roughly 4 MB of witness-heavy data) is rarely achieved. The actual average block size has increased from around 1 MB pre-SegWit to roughly 1.5 to 2 MB: meaningful but below the theoretical maximum.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.