# SegWit explained: what Segregated Witness changed in Bitcoin, and how it activated in 2017

SegWit is a Bitcoin soft fork activated at block 481,824 on 24 August 2017. It separates witness data from the transaction identifier and addresses involuntary malleability for appropriately signed SegWit transactions. It measures blocks by weight, capped at 4,000,000 units, with capacity gains that depend on transaction composition. BIP173 later specified native version-0 addresses beginning bc1q on mainnet.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [Block 481,824](https://blockstream.info/api/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893); [BIP 173: Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki)

Canonical: https://degreesofsatoshi.com/encyclopedia/segwit-explained/
Published: 2026-09-23
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:22:07.965Z

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Proposal:** BIP141, by Eric Lombrozo, Johnson Lau and Pieter Wuille ([BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki))
- **Software:** Bitcoin Core 0.13.1, released 27 October 2016 ([Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/))
- **Signaling rule:** Bit 1; 95% of a 2,016-block period; tracking from 15 November 2016 ([Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki))
- **Activated:** Block 481,824, 24 August 2017, 01:57 UTC ([Mainnet consensus parameters (src/kernel/chainparams.cpp)](https://raw.githubusercontent.com/bitcoin/bitcoin/69142eacd1374925cc9e4ea736c21fcec16307d0/src/kernel/chainparams.cpp); [Block 481,824](https://blockstream.info/api/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893))
- **Block limit:** 4,000,000 weight units, replacing the 1 MB size limit ([BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki))
- **Capacity:** The 0.13.1 release notes estimated about 70% more transactions for typical use if wallets adopt SegWit; actual gains depend on transaction mix ([Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/))
- **Address format:** BIP173 Bech32 encodes native SegWit version-0 mainnet addresses beginning bc1q ([BIP 173: Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki))

## SegWit moved signatures out of the part of a transaction that gets its ID

A Bitcoin transaction has two jobs. It says which coins are being spent and where they are going, and it proves the spender is allowed to do that, usually with a digital signature. Before SegWit, both parts lived in one blob of data, and the transaction ID (the txid, the hash that wallets and explorers use to refer to a transaction) was computed over all of it, signatures included.

BIP141, the proposal written by Eric Lombrozo, Johnson Lau and Pieter Wuille, changed that. The signature data, which the proposal calls the “witness,” is carried in a separate structure that is committed to the block through the coinbase transaction but is not part of the txid. A transaction now has two identifiers: the familiar txid, computed without the witness, and a new wtxid that includes it.

The upgrade was designed as a soft fork, meaning the new rules are stricter than the old ones rather than incompatible with them. A node running older software still sees SegWit blocks as valid and keeps following the chain; it simply does not check the witness data itself. Bitcoin Core’s release notes for version 0.13.1 describe it as allowing software to “separate (segregate) transaction signatures (witnesses) from the part of the data in a transaction that is covered by the txid.” If the distinction is new to you, our [soft forks and hard forks](/encyclopedia/soft-forks-and-hard-forks/) article explains it.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/)

## The malleability fix has specific signing conditions

Signatures have a quirk. With the signature scheme Bitcoin used, a third party who sees a transaction can tweak the signature into a different but still valid form without knowing the private key. The transaction still spends the same coins to the same places, but its txid changes. This is called transaction malleability, and for years it was a nuisance at best and a real problem at worst, because any software that tracked a payment by its ID could lose sight of it.

Because the SegWit txid no longer includes the signature, tweaking the signature no longer changes the ID. BIP141 puts it bluntly: “Nonintentional malleability becomes impossible.” The Bitcoin Core release notes say the change “solves all known cases of unwanted transaction malleability.”

That sounds like housekeeping, but it unlocked something bigger. Protocols that build chains of transactions before they are confirmed, where one transaction spends the output of another that has not reached the chain yet, need the earlier transaction’s ID to be stable. BIP141 lists the ability to create “unconfirmed transaction dependency chains without counterparty risk” as a direct benefit, and Bitcoin Core’s benefits page notes that with malleability fixed, the Lightning Network “is less complicated to implement.” The [Lightning Network](/encyclopedia/lightning-network-explained/) is the best-known thing built on that foundation.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [Segregated Witness Benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/)

## Blocks are now measured in weight, not bytes

Before SegWit, a block could hold at most 1 MB of transaction data. BIP141 replaced that limit with a new measure called block weight. Every byte of witness data counts as one weight unit, and every other byte counts as four. The maximum block weight is 4,000,000 units. Put another way, weight equals the size of the block without witnesses times three, plus its full size.

The effect is a discount for signatures. A block made entirely of old-style transactions still fits about 1 MB, because every byte costs four units. A block full of SegWit transactions fits more, because a large share of each transaction is signature data that now costs a quarter as much. Bitcoin Core’s release notes estimated that “if all wallets switch to using segwit, the network will be able to support about 70% more transactions.” The benefits page describes the practical outcome as an effective limit “closer to 1.6 to 2 MB.”

So SegWit was a capacity increase, but a conditional one that depended on wallets adopting the new transaction format. That framing matters for understanding the politics. One camp saw a signature discount that fit within a soft fork as the responsible way to grow; another wanted a plain increase in the block size, which needs a hard fork. That argument, and the way it was eventually resolved, is the subject of our dossier on the [block size war](/history/bitcoin-block-size-war/). This article stays with what the upgrade actually did.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [Segregated Witness Benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/)

## Two quieter fixes: faster signature checks and safer hardware wallets

BIP143, a companion proposal by Johnson Lau and Pieter Wuille, changed how the data that a signature covers is assembled for SegWit transactions. Under the old method, checking every signature in a large transaction meant re-hashing almost the whole transaction for each one, so the work grew with the square of the transaction’s size. The proposal describes that growth as O(n²) and replaces it with a method that lets hashes be reused, so the work grows in a straight line instead.

The same proposal put the amount being spent into the data a signature covers. Before, a hardware wallet that signed offline could not be sure how much a given input was worth without being handed the entire previous transaction, which BIP143 calls “a big obstacle.” With the value committed in the signature, a device can be shown the amount and refuse to sign if it is wrong.

SegWit also introduced script versioning. Each witness program carries a version number, and Bitcoin Core’s release notes say this “makes it easy for future soft forks” to change the scripting language for users who opt in. That hook is exactly what [Taproot](/encyclopedia/taproot-explained/) used four years later.

Evidence: [BIP 143: Transaction Signature Verification for Version 0 Witness Program](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0143.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/)

## Native version-0 SegWit addresses use bc1q

Native SegWit outputs needed a way to be written down, and BIP173, by Pieter Wuille and Greg Maxwell, supplied one. The format is called Bech32. A mainnet Bech32 address begins with the letters bc, then the digit 1, then a string of lowercase characters drawn from an alphabet that leaves out easily confused letters.

The proposal lists what was wrong with the older base58 addresses: their mixed case makes them “inconvenient to reliably write down, type on mobile keyboards, or read out loud,” they use a lot of space in QR codes, and their checksum “has no error-detection guarantees.” Bech32 addresses are one case throughout and use a checksum that is guaranteed to catch up to four mistyped characters.

Old addresses did not stop working, and you can still send to and from them. But a native SegWit address gets the full weight discount, so payments from it are cheaper. Our guide to [Bitcoin address types](/encyclopedia/bitcoin-address-types/) walks through the formats side by side.

Evidence: [BIP 173: Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki)

## How it activated: nine months of signaling, then block 481,824

Bitcoin Core 0.13.1, released on 27 October 2016, shipped SegWit with its activation switch set. The mechanism was BIP9 version bits: miners could signal readiness by setting bit 1 in the blocks they produced, and if 95% of the blocks in a 2,016-block period signaled, the change would lock in and activate one period later. Tracking began with the first period after 15 November 2016.

For most of a year, the threshold was not met. What happened in between, including the user-activated soft fork proposal, the New York Agreement, BIP91 and the Bitcoin Cash split, is a story about who gets to decide what Bitcoin is, and our [block size war dossier](/history/bitcoin-block-size-war/) lays out the evidence step by step.

The outcome is not in dispute. Bitcoin Core’s own mainnet parameters record the activation height as 481,824, and a block explorer shows that block was mined by BTCC Pool on 24 August 2017 at 01:57 UTC with 1,866 transactions in it. From that block on, every node running SegWit rules has enforced them.

Evidence: [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [Mainnet consensus parameters (src/kernel/chainparams.cpp)](https://raw.githubusercontent.com/bitcoin/bitcoin/69142eacd1374925cc9e4ea736c21fcec16307d0/src/kernel/chainparams.cpp); [Block 481,824](https://blockstream.info/api/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893)

## Use transaction weight to understand the fee comparison

BIP141 defines transaction weight as three times the base size plus the total size, and virtual size as weight divided by four, rounded up. In an illustrative transaction with a 100-byte base size and 300-byte total size, weight is 600 units and virtual size is 150 vbytes. This is an arithmetic example, not a typical transaction estimate.

That accounting explains why moving witness data can change the virtual size used in a fee comparison. It does not make every SegWit transaction a fixed percentage cheaper. Input and output types and the data actually included determine the sizes being compared.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki)

## Questions

### What does SegWit stand for?

Segregated Witness. In Bitcoin’s vocabulary the “witness” is the data that proves you are allowed to spend a coin, usually a signature. SegWit segregates that data into its own section of the transaction, outside the part that produces the transaction ID.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki)

### Did SegWit increase the block size?

Yes, but not to a fixed number of megabytes. It replaced the 1 MB limit with a 4,000,000 weight-unit limit that discounts signature data. Bitcoin Core estimated about 70% more transactions if every wallet used SegWit, and described the effective limit as closer to 1.6 to 2 MB.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/); [Segregated Witness Benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/)

### When did SegWit activate?

At block 481,824, mined on 24 August 2017 at 01:57 UTC. Bitcoin Core’s mainnet parameters record that height as the point where SegWit rules became active.

Evidence: [Mainnet consensus parameters (src/kernel/chainparams.cpp)](https://raw.githubusercontent.com/bitcoin/bitcoin/69142eacd1374925cc9e4ea736c21fcec16307d0/src/kernel/chainparams.cpp); [Block 481,824](https://blockstream.info/api/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893)

### Do I have to use a SegWit address?

No. Older address formats still work. Mainnet native version-0 SegWit addresses start with bc1q and use Bech32. Witness data receives a weight discount, but a fee comparison still depends on the complete transaction and the chosen fee rate. The address format alone does not guarantee a particular saving.

Evidence: [BIP 173: Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki); [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki)

### Was SegWit a hard fork?

No. SegWit was deployed as a soft fork: blocks that follow the added rules remain compatible with the older rules. Older nodes do not enforce all SegWit spending requirements; upgraded nodes check them. Compatibility does not mean that all software versions perform the same validation.

Evidence: [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki); [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/)

## Claims and scope

### segwit-explained-quick-answer

SegWit is a Bitcoin soft fork activated at block 481,824 on 24 August 2017. It separates witness data from the transaction identifier and addresses involuntary malleability for appropriately signed SegWit transactions. It measures blocks by weight, capped at 4,000,000 units, with capacity gains that depend on transaction composition. BIP173 later specified native version-0 addresses beginning bc1q on mainnet.

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-proposal

Proposal: BIP141, by Eric Lombrozo, Johnson Lau and Pieter Wuille

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-software

Software: Bitcoin Core 0.13.1, released 27 October 2016

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-signaling-rule

Signaling rule: Bit 1; 95% of a 2,016-block period; tracking from 15 November 2016

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-activated

Activated: Block 481,824, 24 August 2017, 01:57 UTC

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-block-limit

Block limit: 4,000,000 weight units, replacing the 1 MB size limit

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-capacity

Capacity: The 0.13.1 release notes estimated about 70% more transactions for typical use if wallets adopt SegWit; actual gains depend on transaction mix

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### segwit-explained-fact-address-format

Address format: BIP173 Bech32 encodes native SegWit version-0 mainnet addresses beginning bc1q

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

## Sources

- [BIP 141: Segregated Witness (Consensus layer)](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0141.mediawiki) — Bitcoin Improvement Proposals repository on GitHub. Defines the witness structure and wtxid, states that nonintentional malleability becomes impossible, sets block weight at base size times three plus total size with a 4,000,000 limit, and records the BIP9 bit 1 deployment. Locator: Defines the witness structure and wtxid, states that nonintentional malleability becomes impossible, sets block weight at base size times three plus total size with a 4,000,000 limit, and records the BIP9 bit 1 deployment.. Retrieved: 2026-10-02T15:04:13.421045+00:00.
- [BIP 143: Transaction Signature Verification for Version 0 Witness Program](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0143.mediawiki) — Bitcoin Improvement Proposals repository on GitHub. Replaces quadratic (O(n²)) signature hashing with a linear method and commits the input value so offline signers need not fetch the whole previous transaction. Locator: Replaces quadratic (O(n²)) signature hashing with a linear method and commits the input value so offline signers need not fetch the whole previous transaction.. Retrieved: 2026-10-02T15:04:18.713619+00:00.
- [BIP 173: Base32 address format for native v0-16 witness outputs](https://raw.githubusercontent.com/bitcoin/bips/927b6de9915c9262615a6399de51b200f81e5aa4/bip-0173.mediawiki) — Bitcoin Improvement Proposals repository on GitHub. Specifies Bech32 addresses with the bc prefix and lists the problems with base58: mixed case, QR code inefficiency and a checksum with no error-detection guarantees. Locator: Specifies Bech32 addresses with the bc prefix and lists the problems with base58: mixed case, QR code inefficiency and a checksum with no error-detection guarantees.. Retrieved: 2026-10-02T15:04:13.515182+00:00.
- [Bitcoin Core version 0.13.1 released](https://bitcoincore.org/en/releases/0.13.1/) — Bitcoin Core (bitcoincore.org). Release notes describing segwit, its 95% signaling threshold on bit 1 from 15 November 2016, the estimate of about 70% more transactions, and the statement that it solves all known cases of unwanted malleability. Locator: Release notes describing segwit, its 95% signaling threshold on bit 1 from 15 November 2016, the estimate of about 70% more transactions, and the statement that it solves all known cases of unwanted malleability.. Retrieved: 2026-10-02T14:48:56.872086+00:00.
- [Segregated Witness Benefits](https://bitcoincore.org/en/2016/01/26/segwit-benefits/) — Bitcoin Core (bitcoincore.org). Explains each benefit, including the effective capacity of closer to 1.6 to 2 MB and the observation that fixed malleability makes the Lightning Network less complicated to implement. Locator: Explains each benefit, including the effective capacity of closer to 1.6 to 2 MB and the observation that fixed malleability makes the Lightning Network less complicated to implement.. Retrieved: 2026-10-02T14:48:56.818048+00:00.
- [Mainnet consensus parameters (src/kernel/chainparams.cpp)](https://raw.githubusercontent.com/bitcoin/bitcoin/69142eacd1374925cc9e4ea736c21fcec16307d0/src/kernel/chainparams.cpp) — Bitcoin Core repository on GitHub. Records consensus.SegwitHeight = 481824 for mainnet, the block at which SegWit rules are enforced. Locator: Records consensus.SegwitHeight = 481824 for mainnet, the block at which SegWit rules are enforced.. Retrieved: 2026-10-02T15:04:11.761623+00:00.
- [Block 481,824](https://blockstream.info/api/block/0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893) — Blockstream Esplora. Shows the SegWit activation block mined by BTCC Pool on 24 August 2017 at 01:57 UTC with 1,866 transactions. Locator: JSON fields height, timestamp, id; block height 481824. Retrieved: 2026-10-02T15:25:01.715429+00:00.

## Revision history

- 2026-09-23: Initial Bitcoin encyclopedia entry at this permanent URL.
- 2026-10-02: Revised direct answer to preserve source scope and qualifications. Corrected key fact: Capacity Corrected key fact: Address format
- 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.
- 2026-10-02: Added “Use transaction weight to understand the fee comparison”, clarified the search description, and corrected overbroad section headings. Independent verification is recorded separately.

## Cite this entry

Degrees of Satoshi editorial project. “SegWit explained: what Segregated Witness changed in Bitcoin, and how it activated in 2017.” Published 2026-09-23; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/segwit-explained/