# What is SegWit?

Source URL: https://help.blockstream.com/education/development/how-bitcoin-evolves/what-is-segwit
Updated: 2026-09-28T18:13:11.000Z
Category: Development
Section: How Bitcoin Evolves

---

**TL;DR:** Segregated Witness (SegWit) is a Bitcoin protocol upgrade activated in August 2017 that separates digital signature data from transaction data. This fixed a long-standing bug called transaction malleability, increased effective block capacity through a new weight-based measurement system, reduced transaction fees, and made the Lightning Network possible. 

**Segregated Witness (SegWit)** is a soft fork upgrade to the Bitcoin protocol that restructures how transaction data is stored in blocks. By moving signature data (the "witness") into a separate structure outside the traditional transaction format, SegWit fixed transaction malleability, introduced a new block weight measurement (4 million weight units per block), and enabled second-layer protocols like the Lightning Network. 

## The Problem SegWit Solved

To understand why SegWit was built, you need to understand the bug it fixed: **transaction malleability**.

Every Bitcoin transaction has a unique identifier called a transaction ID (txid). This ID is calculated by hashing all the transaction data, including the digital signatures that prove ownership of the bitcoin being spent. The problem: signatures in Bitcoin's original design could be slightly modified without invalidating them. A third party (or even a miner) could tweak the signature encoding before a transaction was confirmed, changing its txid while keeping the transaction itself valid.

Any system that relied on tracking unconfirmed transactions by their txid could be broken. If you sent a transaction and then tried to build a second transaction that spent the change from the first, a malleated txid would make the second transaction invalid. Payment channels, which require chaining transactions together before broadcasting them, were unreliable as long as txids could be altered.

### Why It Mattered Beyond the Bug Fix

Transaction malleability was more than an inconvenience. It was a hard blocker for building payment channel networks on top of Bitcoin. The [Lightning Network](https://help.blockstream.com/education/glossary/lightning-network) design required the ability to create chains of pre-signed transactions where each transaction referenced the txid of the previous one. If any txid in the chain could be altered, the entire channel became unsafe. Until malleability was fixed, the Lightning Network could not work securely.

The 2014 Mt. Gox collapse also brought malleability into public awareness. Mt. Gox claimed that transaction malleability was exploited to confuse its accounting systems, causing it to re-send withdrawals. While the full extent of malleability's role in Mt. Gox's failure remains debated, the incident demonstrated that the bug had real-world financial consequences.

## How SegWit Works

SegWit's core mechanism is in its name: it **segregates** (separates) the **witness** (signature data) from the rest of the transaction.

### The Witness Structure

In a pre-SegWit (legacy) transaction, the scriptSig field contains the digital signature and public key needed to authorize spending. This data is included in the txid hash, which is what made malleability possible.

SegWit moves this signature data into a new structure called the "witness," appended to the transaction but excluded from the txid calculation. The result: even if someone modifies the witness data, the txid stays the same. Transaction malleability is eliminated for SegWit transactions.

The witness data still gets committed to the block through a separate commitment in the coinbase transaction, the first transaction in every block that pays the miner, so it remains fully validated by the network. Nothing is lost. The data simply lives in a different place.

### Backward Compatibility: The Soft Fork Design

SegWit was specified across three BIPs: [BIP 141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki) (the consensus rules and witness structure), [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) (a new transaction digest algorithm for signature verification that eliminates quadratic hashing), and [BIP 144](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki) (the peer-to-peer protocol changes for relaying witness data). Together, these three proposals form the complete SegWit specification. SegWit was designed as a soft fork, meaning it was backward compatible with older Bitcoin software. Nodes that had not upgraded could still validate blocks containing SegWit transactions. From their perspective, SegWit outputs looked like "anyone-can-spend" transactions, but the upgraded majority of the network enforced the actual spending rules.

This design choice was deliberate. A hard fork would have split the network, requiring every node to upgrade simultaneously. A soft fork allowed gradual adoption while maintaining a single chain.

## Block Weight: A New Way to Measure Blocks

Before SegWit, Bitcoin blocks had a hard 1 MB size limit. Every byte in a transaction counted equally toward this limit. SegWit replaced this with a new measurement called **block weight**, measured in weight units (WU).

### The Weight Calculation

Block weight applies different multipliers to different parts of a transaction. The scaling factor is defined as **WITNESS\_SCALE\_FACTOR = 4** in [Bitcoin Core](https://help.blockstream.com/education/nodes/set-up-and-optimization/what-is-bitcoin-core)'s [**consensus/consensus.h**](https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h):

- **Non-witness data** (inputs, outputs, transaction metadata): 4 weight units per byte
- **Witness data** (signatures, public keys): 1 weight unit per byte

The formula for any transaction is: **weight = (non-witness bytes × 4) + (witness bytes × 1)**. Virtual size (vsize), which fee estimation uses, equals weight divided by 4, rounded up.

The maximum block weight is 4,000,000 WU (4 million weight units), defined as **MAX\_BLOCK\_WEIGHT = 4000000** in the same file. A block filled entirely with legacy (non-witness) transactions would still max out at roughly 1 MB, since every byte costs 4 WU and 1,000,000 bytes × 4 = 4,000,000 WU. But a block containing SegWit transactions effectively fits more data because witness bytes are discounted.

### Under the Hood: Weight Unit Calculation

A worked example makes the weight system concrete. Consider a typical single-input, two-output native SegWit (P2WPKH) transaction. The non-witness data (version, marker, flag, input count, outpoint, sequence, output count, two outputs, locktime) totals approximately 113 bytes. The witness data (signature plus public key) adds approximately 107 bytes. Applying the formula:

**(113 × 4) + (107 × 1) = 452 + 107 = 559 WU**

The virtual size is 559 / 4 = 140 vbytes (rounded up). Compare the same payment from a legacy P2PKH address, where all data counts as non-witness: approximately 226 bytes × 4 = 904 WU, or 226 vbytes. The SegWit transaction consumes roughly 62% of the weight (a 38% reduction), producing proportional fee savings.

The savings grow with more inputs. A 10-input consolidation transaction carries 10 signatures in the witness. Each signature benefits from the 4:1 discount, and the total weight reduction compared to legacy can exceed 50%. This is why [UTXO](https://help.blockstream.com/education/transactions/transaction-basics/what-are-utxos) consolidation during low-fee periods is significantly cheaper with SegWit addresses.

In practice, blocks with a high proportion of SegWit transactions can hold approximately 2 to 2.3 MB of raw data. The theoretical maximum is about 4 MB, though this would require an unrealistic block composition of almost entirely witness data.

### Why Discount Witness Data?

The discount reflects a technical reality: witness data is only needed during transaction validation. Once a transaction is confirmed deep in the blockchain, nodes can optionally prune the witness data because it is no longer needed to verify the current UTXO set. Non-witness data (which inputs are being spent, which outputs are being created) is needed indefinitely. The weight discount aligns the fee structure with the long-term cost each byte imposes on the network.

## SegWit Address Formats

SegWit introduced new address formats that reflect different levels of the upgrade. Understanding these formats helps you identify transaction types and estimate fee efficiency.

### P2SH-Wrapped SegWit (Starts With 3)

The earliest SegWit addresses were wrapped inside Pay-to-Script-Hash (P2SH) addresses, which start with the number 3\. This format (technically P2SH-P2WPKH) was a compatibility bridge. It allowed senders using older wallets that did not recognize SegWit to send to SegWit recipients. The SegWit spending rules were hidden inside the P2SH script.

These addresses provide partial fee savings over legacy addresses because the witness discount applies to the spending transaction. However, the P2SH wrapping adds extra bytes, so the savings are not as large as native SegWit.

### Native SegWit / Bech32 (Starts With bc1q)

Native SegWit addresses use the bech32 encoding format defined in [BIP 173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) and start with **bc1q**. These addresses (technically P2WPKH for single-key, P2WSH for script) provide the full fee discount because there is no P2SH wrapping overhead.

Bech32 addresses are also designed to be more error-resistant than legacy formats. They use a different character set (no mixed case) and include a built-in error-detection mechanism that can identify up to four character errors.

Most modern wallets generate native SegWit addresses by default. The Blockstream app, for example, uses native SegWit as its default address format when paired with a Jade [hardware wallet](https://help.blockstream.com/education/wallets/security-and-storage/what-is-a-hardware-wallet), giving users the full fee benefit without requiring any configuration.

### Taproot / Bech32m (Starts With bc1p)

The [Taproot](https://help.blockstream.com/education/development/how-bitcoin-evolves/what-is-taproot) upgrade (activated November 2021) introduced a third SegWit address format using bech32m encoding, starting with **bc1p**. Taproot addresses (P2TR) build on SegWit's witness structure but add [Schnorr signatures](https://help.blockstream.com/education/glossary/schnorr-signatures) and Merklized Abstract Syntax Trees (MAST, built on a [Merkle tree](https://help.blockstream.com/education/glossary/merkle-tree)), enabling more complex spending conditions with greater privacy and efficiency.

Taproot addresses are SegWit version 1, while native SegWit (bech32) addresses are SegWit version 0\. Both use the witness data structure that SegWit introduced.

P2TR outputs expose the public key itself on-chain at funding time, in Taproot's x-only form, rather than exposing only a hash of it. That leaves them quantum-exposed alongside the early pay-to-public-key (P2PK) format instead of hidden like P2PKH and P2WPKH outputs, until a quantum-safe spending path activates.

| Address Format         | Prefix | SegWit Version | Fee Savings vs. Legacy | Notes                   |
| ---------------------- | ------ | -------------- | ---------------------- | ----------------------- |
| Legacy (P2PKH)         | 1      | N/A            | Baseline               | No witness discount     |
| P2SH-wrapped SegWit    | 3      | v0 (wrapped)   | \~26% smaller          | Compatibility bridge    |
| Native SegWit (bech32) | bc1q   | v0             | \~38% smaller          | Full witness discount   |
| Taproot (bech32m)      | bc1p   | v1             | \~15-30% smaller       | Varies by spending path |

## Fee Savings From SegWit

SegWit reduces fees because witness data is cheaper per byte. The worked example above shows the effect: roughly a 38% weight reduction for a typical single-input, two-output payment, which translates directly into lower fees at any given fee rate.

The savings compound for transactions with multiple inputs. Each input carries signature data, and each signature benefits from the witness discount. A transaction consolidating ten UTXOs saves significantly more than a simple one-input payment.

You can compare the weight and fee difference between legacy and SegWit transactions directly on [Blockstream Explorer](https://blockstream.info/). Each transaction displays its weight in WU alongside its size in virtual bytes (vbytes), making it straightforward to see how the witness discount affects actual fee costs.

## How SegWit Enabled the Lightning Network

The [Lightning Network](https://help.blockstream.com/education/glossary/lightning-network) is a [layer-2](https://help.blockstream.com/education/glossary/layer-2) payment channel network that enables fast, low-cost Bitcoin payments. Its fundamental building block is the payment channel: two parties lock bitcoin into a 2-of-2 multisig address and then exchange signed transactions off-chain, settling back to the Bitcoin blockchain only when necessary.

This design requires each party to hold pre-signed "commitment transactions" that can be broadcast at any time to claim their balance. These commitment transactions reference the txid of the funding transaction (the on-chain transaction that opened the channel). If a third party could malleate the funding transaction's txid, every commitment transaction would become invalid, and the channel funds could be held hostage.

SegWit eliminated this attack vector entirely. With witness data excluded from the txid calculation, the funding transaction's ID is fixed the moment it is created. Commitment transactions that reference it remain valid regardless of how the funding transaction is eventually included in a block.

Without SegWit, building the Lightning Network on Bitcoin would have required an entirely different approach to transaction chaining. SegWit made Lightning practical.

## The Activation Controversy

SegWit's technical design was relatively uncontroversial among protocol developers. The code was merged into Bitcoin Core in October 2016\. But the path to activation became one of the most contentious episodes in Bitcoin's history, revealing deep tensions about who controls the Bitcoin protocol.

### The Block Size Debate

SegWit arrived in the middle of the "block size war." One faction advocated increasing the block size limit directly (e.g., Bitcoin XT, Bitcoin Classic, Bitcoin Unlimited). Another faction preferred SegWit's approach of increasing effective capacity without changing the base block size limit, combined with layer-2 solutions like Lightning for scaling.

Some large mining pools, particularly those tied to Bitmain, signaled that they would not activate SegWit unless it was bundled with a hard fork block size increase. This created a political stalemate: SegWit had majority support among users and developers but lacked the 95% miner signaling threshold required by [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) (the activation mechanism in use at the time).

### BIP 148 and the User-Activated Soft Fork (UASF)

In early 2017, a grassroots movement emerged advocating for [BIP 148](https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki), a User-Activated Soft Fork (UASF). BIP 148 proposed that on August 1, 2017, nodes running the UASF code would reject any block that did not signal support for SegWit, regardless of whether the 95% miner threshold had been reached.

The UASF movement represented a philosophical claim: that Bitcoin's consensus rules are ultimately determined by the economic nodes (users, businesses, exchanges) that define what constitutes a valid block, not by miners alone. If enough of the economy ran UASF nodes, miners who did not signal SegWit would find their blocks rejected by a significant portion of the network.

### The SegWit2x Compromise

Under pressure from the UASF threat, a group of businesses and miners signed the "New York Agreement" in May 2017, proposing SegWit2x: activate SegWit first, then hard fork to 2 MB base blocks three months later. This satisfied miners who wanted a block size increase while delivering SegWit to those who wanted it.

SegWit locked in on August 8, 2017, and activated on August 24, 2017\. But the second part of SegWit2x (the 2 MB hard fork) never happened. As the November hard fork date approached, support collapsed. Several major companies withdrew, and the fork was called off. SegWit continued to operate on its own, without the additional block size hard fork.

### What the Activation Revealed About Bitcoin Governance

The SegWit activation saga demonstrated several principles about how Bitcoin governance actually works:

- **Miners do not control the protocol.** Despite significant hashrate opposition, SegWit activated because economic nodes enforced it. Miners produce blocks, but nodes decide which blocks are valid.
- **Users have veto power.** The UASF proved that a coordinated user base can force protocol changes that miners resist, or block changes that users oppose.
- **Private agreements do not bind the network.** The New York Agreement was signed by a small group of companies. The broader Bitcoin community was not party to it and ultimately rejected the 2x hard fork component.
- **Soft forks preserve network unity.** Because SegWit was backward compatible, the network stayed on a single chain, and nodes that did not upgrade continued to validate blocks. The Bitcoin Cash hard fork (August 1, 2017) shows the contrast, permanently splitting the chain into two.

## SegWit Adoption and Current Usage

SegWit adoption grew slowly in its first year. By early 2018, only about 30-35% of Bitcoin transactions used SegWit. Major exchanges and wallets were slow to upgrade, and some criticized the pace of adoption.

Adoption accelerated steadily after 2018 as wallets and exchanges implemented native SegWit support. By 2022, SegWit usage had crossed 85% of all Bitcoin transactions. As of early 2026, the vast majority of Bitcoin transactions use some form of SegWit (including Taproot, which builds on SegWit's witness structure).

The remaining non-SegWit transactions come primarily from older wallets and services that have not upgraded, as well as specific use cases that still rely on legacy address formats. The trend is clear: SegWit has become the standard transaction format on the Bitcoin network.

### Block Weight Utilization

With high SegWit adoption, average block sizes have increased well beyond the old 1 MB limit. Typical blocks now contain 1.5 to 2.5 MB of raw data, with the variation depending on the mix of transaction types and the proportion of witness data. During periods of high demand (such as the Ordinals and BRC-20 activity in 2023), blocks have regularly approached 3.5 to 4 MB as transactions with large witness sections fill the available weight.

## SegWit's Lasting Impact

SegWit was more than a capacity increase or a bug fix. It restructured how Bitcoin processes and stores transaction data, creating a foundation for future protocol development.

### Script Versioning

SegWit introduced script versioning through its witness program structure. The witness version byte (v0 for the initial SegWit, v1 for Taproot) allows future soft forks to define entirely new spending rules without conflicting with existing ones. This made Taproot's activation straightforward: it defined v1 witness rules, and the existing SegWit framework handled the rest.

Future upgrades (v2, v3, and beyond) can follow the same pattern, each adding new capabilities without disrupting existing transaction types.

### A Blueprint for Protocol Upgrades

The SegWit activation process, for all its controversy, established patterns that influenced subsequent upgrades. Taproot's activation in 2021 used "Speedy Trial," a [BIP 9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki) variant designed to avoid the prolonged signaling standoffs that plagued SegWit. (BIP 8, with its LOT parameter, was a separate proposal that was not adopted for Taproot activation.) The lesson from SegWit's activation was clear: define the activation parameters conservatively, rely on broad community consensus before deployment, and keep the window short.

## Frequently Asked Questions

### Is SegWit mandatory? Do all Bitcoin users need to upgrade?

SegWit is not mandatory for individual users. Legacy addresses still work, and you can still send and receive bitcoin using pre-SegWit transaction formats. However, using SegWit addresses results in lower fees, and most modern wallets default to SegWit or Taproot addresses. There is no practical reason to use legacy addresses for new transactions.

### Does SegWit change the total supply of bitcoin?

No. SegWit changes how transaction data is structured and measured, but it does not alter the 21 million bitcoin supply cap, the mining reward schedule, or any monetary policy parameters.

### What is the difference between SegWit and Taproot?

Taproot builds on SegWit. Both use the witness data structure, but Taproot (SegWit version 1) adds Schnorr signatures and MAST, which improve privacy and enable more efficient complex spending conditions. SegWit (version 0) fixed malleability and introduced the weight system. Taproot extended these benefits with new signature and scripting capabilities.

### How much do SegWit transactions save on fees?

A typical native SegWit (bc1q) transaction is roughly 38% lighter than an equivalent legacy transaction. Taproot transactions provide similar or slightly better savings depending on the spending path. The exact savings depend on the number of inputs and outputs, but SegWit consistently costs less than legacy at any fee rate.

### Can I send bitcoin from a legacy address to a SegWit address?

Yes. You can send bitcoin between any combination of legacy, P2SH-wrapped SegWit, native SegWit, and Taproot addresses. The address format determines the spending rules for the recipient, not the sender. The fee savings apply when the bitcoin is spent from a SegWit address, not when it is received.

### How do I know if my Bitcoin address is SegWit?

Check the address prefix. A **bc1q** prefix is native SegWit (bech32), and **bc1p** is Taproot (bech32m), which builds on SegWit. A leading 3 may be P2SH-wrapped SegWit or a legacy multisig script, while a leading 1 is always a legacy address with no witness discount. Most modern wallets generate **bc1q** or **bc1p** addresses by default.

### Did SegWit increase Bitcoin's block size?

SegWit replaced the 1 MB block size limit with a 4 million weight unit (4 MWU) block weight limit, defined as **MAX\_BLOCK\_WEIGHT** in Bitcoin Core's consensus code. Because witness data is discounted (1 WU per byte vs. 4 WU per byte for non-witness data, scaled by **WITNESS\_SCALE\_FACTOR = 4**), blocks can contain more total data than before. Typical blocks are now 1.5 to 2.5 MB. The theoretical maximum is about 4 MB, though this is rarely approached in practice.

Navigation: Blockstream Help Center > Education > Development > What is SegWit?

## Related Articles in This Section
- [Bitcoin's open-source ecosystem](https://help.blockstream.com/education/development/how-bitcoin-evolves/bitcoins-open-source-ecosystem)
- [How do Bitcoin upgrades work?](https://help.blockstream.com/education/development/how-bitcoin-evolves/how-do-bitcoin-upgrades-work)
- [What is SegWit?](https://help.blockstream.com/education/development/how-bitcoin-evolves/what-is-segwit) (current)
- [What is Simplicity?](https://help.blockstream.com/education/development/how-bitcoin-evolves/what-is-simplicity)
- [What is Taproot?](https://help.blockstream.com/education/development/how-bitcoin-evolves/what-is-taproot)
- [Who works on Bitcoin?](https://help.blockstream.com/education/development/how-bitcoin-evolves/who-works-on-bitcoin)
- [Why doesn't Bitcoin have more features?](https://help.blockstream.com/education/development/how-bitcoin-evolves/why-doesnt-bitcoin-have-more-features)