SegWit Explained: Block Weight, Fees, and Addresses

Segregated Witness, or SegWit, is a Bitcoin soft fork that separates witness data from the transaction serialization used for the transaction identifier (txid). Witness data remains part of the full transaction and block; it is not moved off-chain. BIP141 introduces new validation and block-weight rules while preserving compatibility with legacy nodes’ view of a block.

SegWit caps block weight at 4,000,000 weight units. Non-witness bytes count four times and witness bytes once. The total serialized byte size therefore depends on transaction composition and can approach 4 MB in witness-heavy blocks; 1.8–2.1 MB is not a protocol limit. A virtual byte corresponds to four weight units, rounded up for a transaction’s virtual size. (Source: BIP141 Segregated Witness)

SegWit removes witness data from txid calculation, addressing involuntary witness-based malleability for qualifying transactions. It does not make every transaction identifier immutable: changing non-witness fields, replacing a transaction, or including malleable legacy inputs can still matter. The improvement makes pre-signed transaction chains easier to construct, including those used by Lightning.

Origin & History

Research background: SegWit builds on earlier discussion of transaction malleability, witness separation, and compatible protocol upgrades.

December 2015: Pieter Wuille presents Segregated Witness at Scaling Bitcoin in Hong Kong, explaining its malleability and capacity benefits.

Technical specifications: BIP141 defines consensus changes, BIP143 specifies signature hashing for version-0 witness programs, and BIP144 describes peer-service and serialization changes. These are distinct specifications with different scopes and authorship.

May 2017: Litecoin activated SegWit on its network ahead of Bitcoin, serving as a real-world testbed that demonstrated the upgrade’s stability and security in a production environment. Litecoin’s successful activation bolstered confidence in deploying SegWit on Bitcoin.

July–August 2017: BIP91, BIP148, and the existing activation process play different roles in the contentious SegWit deployment period. Bitcoin Cash splits on August 1; SegWit itself activates on Bitcoin later that month.

August 24, 2017: SegWit officially activated on the Bitcoin mainnet at block height 481,824. The activation represented the conclusion of one of the most politically charged debates in Bitcoin’s history, often referred to as the “Block Size War.”

After activation: Wallets and services adopt wrapped and native SegWit. Native version-0 mainnet addresses begin bc1q; an address beginning 3 is P2SH and is not necessarily SegWit.

November 2021: Taproot activates using witness version 1, with Schnorr signatures and script-tree commitments.

Current use: SegWit remains part of Bitcoin’s consensus rules. Adoption percentages and public Lightning capacity are changing metrics that require a dated dataset and clear methodology.

In Simple Terms

1. Imagine sending a letter in an envelope. The letter is the actual message (the payment details), and the wax seal is your signature proving it is authentic. Before SegWit, both the letter and the seal had to fit inside one small envelope. SegWit lets you put the seal in a separate, attached pouch — so the main envelope can hold more letters while the seals are still carried along for verification.
2. Think of a shipping rule that charges different weights for two kinds of material. SegWit changes how data counts toward capacity; all required validation data still travels in the full block.
3. Consider a passport control line at an airport. Before SegWit, each traveler had to carry their entire filing cabinet of personal documents through the narrow gate. SegWit is like allowing travelers to pass through the gate with just their passport, while their full document files are sent through a separate, wider channel that runs in parallel.
4. Picture a recipe card with a limited word count. Before SegWit, both the cooking instructions and the footnotes had to fit on one card. SegWit moves the footnotes to the back of the card and counts them at a discount — so chefs can fit more actual cooking steps on the front of each card.
5. Imagine a highway toll booth where each car is charged per passenger. SegWit is like changing the rule so that passengers in the back seat are charged at a quarter of the price — the toll booth still handles the same number of cars, but each car effectively carries more people for the same total toll.

Important: Legacy nodes accept the stripped view under older rules but do not enforce SegWit witness validation. Upgraded nodes enforce those rules. Wallets need compatible scripts and transaction construction to spend SegWit outputs correctly. (Source: BIP144 witness serialization)

Key Technical Features

Block Weight and the New Capacity Model

• Replaces the 1 MB block size limit with a 4,000,000 weight unit (4 MWU) block weight limit
• Non-witness data costs 4 WU per byte; witness data costs 1 WU per byte
• Total serialized size varies with witness composition and can approach 4 MB; transaction count is not fixed.
• Legacy nodes receive a compatible stripped serialization; upgraded nodes also validate the witness commitments and rules.

Transaction Malleability Fix

• Before SegWit, the txid was computed over the entire transaction including signatures
• Historically, allowed changes to unlocking data could alter a txid without changing the intended payment. Which changes are valid depends on the active consensus and policy rules.
• The txid excludes witness data. This prevents witness-only changes from altering it, not every possible modification to the transaction.
• A separate witness txid (wtxid) covers the full transaction including witness data

How a SegWit Transaction Works

1. The sender’s wallet constructs a transaction with inputs referencing previous UTXOs and outputs specifying recipient addresses and amounts
2. Native witness inputs use an empty scriptSig; P2SH-wrapped witness inputs include the redeem witness program. Other inputs in a mixed transaction can still have legacy scriptSigs. (Source: Bitcoin Core SegWit wallet development)
3. The transaction is serialized with a marker byte (0x00) and flag byte (0x01) indicating SegWit format
4. The txid hashes the non-witness serialization, including the actual scriptSig fields; they are not universally empty.
5. The wtxid is calculated by hashing the full serialized transaction including witness data
6. A witness commitment in the coinbase transaction commits to the witness Merkle root, alongside the block’s ordinary transaction Merkle-root structure.
7. Nodes verify both the standard transaction validity and the witness data integrity when validating the block

SegWit Address Types

• P2SH-wrapped SegWit: Mainnet addresses begin 3, but the same prefix also represents non-SegWit P2SH scripts. BIP49 specifies a common wrapped-wallet derivation convention.
• Native version-0 SegWit: Mainnet addresses begin bc1q and use Bech32. Fee savings depend on input and output types, counts, and fee rate.
• Taproot: Mainnet version-1 addresses begin bc1p and use Bech32m. Other future witness versions also use Bech32m but need not begin bc1p.

Lightning Network Enablement

• The Lightning Network relies on pre-signed transactions that reference specific txids
• Transaction malleability before SegWit meant that txids could change after broadcast, breaking payment channel contracts
• Removing witness-based txid malleability supports robust channel construction; Lightning still has its own liquidity, monitoring, and protocol risks.
• Lightning implementations use compatible funding and spending formats; operating a channel requires more than choosing a SegWit address.

Advantages & Disadvantages

Risk Management

Address Compatibility Risk

• Legacy wallets and some exchanges may not support sending to bech32 (bc1) addresses
• Verify that the sending service supports the recipient’s exact address type and network. Wrapped SegWit may provide compatibility in some cases, but do not assume every 3-prefixed address is a SegWit wallet.
• Check current service documentation rather than assuming support from an old adoption date.

Partial Adoption Fee Risk

• The sender pays the transaction fee, which depends on the inputs being spent and the entire transaction. Receiving a SegWit output can lower the cost of spending that output later.
• Use compatible native SegWit outputs where appropriate and compare actual virtual sizes and fee estimates.

Witness Data and Resource Use

• Witness-heavy transactions can produce larger serialized blocks within the weight limit. Using permitted witness space is not inherently a protocol exploit.
• Consensus weight and script rules constrain blocks; node relay and mining policies impose additional, distinct limits. Policy limits should not be confused with consensus limits.
• The 2023 Ordinals and Inscriptions trend demonstrated this dynamic, as large witness data payloads were used to inscribe images and data on-chain

Migration Risk for Services

• Exchanges and payment processors migrating from legacy to SegWit address formats must handle the transition carefully to avoid fund loss or accounting errors
• Mitigation: run parallel legacy and SegWit systems during migration; conduct thorough testing on testnet before mainnet deployment

Cultural Relevance

The scaling debate known as the Block Size War involved competing technical and governance approaches. Bitcoin Cash split on August 1, 2017; Bitcoin SegWit activated on August 24 at height 481,824. These were separate events.

The phrase “UASF” (User-Activated Soft Fork) became a rallying cry among SegWit supporters who advocated for node operators to enforce SegWit activation regardless of miner signaling. The BIP148 UASF movement demonstrated the power of economic nodes (exchanges, businesses, users) over miners in determining Bitcoin’s upgrade path, establishing a precedent for how future protocol changes would be evaluated.

SegWit’s activation also marked a turning point in Bitcoin governance. The failure of the New York Agreement (SegWit2x), which proposed activating SegWit followed by a 2 MB block size increase, reinforced the principle that no closed-door agreement among industry players could dictate Bitcoin’s protocol changes without broader community consensus.

In developer culture, SegWit is celebrated as an elegant engineering solution that solved multiple problems simultaneously — scaling, malleability, and upgradeability — through a single backward-compatible change. The witness versioning system it introduced has become the primary mechanism for deploying subsequent upgrades, with Taproot (witness v1) being the most notable example.

The “Block Size War” has been extensively documented in Jonathan Bier’s book The Blocksize War (2021), which has become recommended reading for anyone seeking to understand Bitcoin’s governance model and the social dynamics of decentralized protocol development.

Real-World Examples

1. SegWit and Transaction Batching

• Scenario: A service wants to reduce the total on-chain cost of many withdrawals.
• Mechanism: SegWit can reduce input weight, while batching shares transaction overhead across multiple outputs. These are separate optimizations.
• Outcome: SegWit and batching can both reduce costs, but their benefits depend on transaction structure and fee rate. Batching shares overhead; SegWit changes the weight of eligible input data.

2. Lightning Network Growth Enabled by SegWit

• Scenario: Payment-channel protocols need reliable references to funding and commitment transactions.
• Implementation: Lightning nodes open payment channels by creating 2-of-2 multisig SegWit transactions on the Bitcoin base layer. Subsequent payments within the channel are conducted off-chain through updated commitment transactions that reference the original SegWit funding transaction’s txid.
• Outcome: SegWit supports Lightning’s transaction design, but channel capacity, routing liquidity, node counts, and payment success are distinct measures. No fixed 2026 capacity or dollar valuation follows from the protocol.

3. Mempool Congestion Relief During the 2021 Bull Run

• Scenario: During the 2021 Bitcoin bull market, transaction volume surged, causing significant mempool congestion and elevated fees.
• Mechanism: At the same fee rate, a lower virtual size reduces the total fee. Inclusion still depends on fee rate, ancestor packages, miner policy, and available block space.
• Outcome: SegWit improves block-space efficiency for appropriate transaction types. It does not guarantee next-block inclusion or a universal two- or three-fold fee advantage.

4. Ordinals and Inscriptions Using Witness Space

• Scenario: In early 2023, developer Casey Rodarmor launched the Ordinals protocol, which uses SegWit’s witness data space to inscribe arbitrary data (images, text, HTML) directly onto the Bitcoin blockchain.
• Mechanism: Inscription data is carried in Taproot script-path witness data and receives witness weighting. Other block and transaction data still consumes weight, so a payload cannot occupy a full 4,000,000 bytes independently of overhead.
• Outcome: Inscriptions illustrate a witness-heavy use of block space and have renewed debate over resource allocation. Counts and adoption figures require a dated dataset.

Comparison Table

Related Terms

• Bitcoin Improvement Proposal (BIP) — The formal process for proposing and documenting changes to the Bitcoin protocol; SegWit was implemented through BIP141, BIP143, and BIP144.
• Transaction Malleability — Changes that alter a transaction identifier without necessarily changing its intended payment; SegWit addresses witness-based forms under specified conditions.
• Lightning Network — Bitcoin’s primary layer-2 payment channel network enabling instant, low-fee transactions; directly enabled by SegWit’s malleability fix.
• Soft Fork — A backward-compatible protocol upgrade where non-upgraded nodes still accept blocks from upgraded nodes; SegWit was deployed as a soft fork to avoid splitting the network.
• Block Weight — The SegWit-introduced metric replacing the legacy block size limit, measured in weight units (WU) with a maximum of 4,000,000 WU per block.
• Bech32 — Address encoding used for native witness version 0; Bech32m is used for versions 1 and later.
• Taproot — A 2021 Bitcoin upgrade building on SegWit’s witness version 1 to introduce Schnorr signatures, MAST, and enhanced privacy for complex transactions.
• UTXO (Unspent Transaction Output) — The fundamental accounting model in Bitcoin; SegWit transactions modify how UTXO spending conditions are structured and verified.
• Witness Program — The scriptPubKey format introduced by SegWit that specifies the witness version and program hash, enabling segregated verification of spending conditions.
• Bitcoin Cash — A hard fork of Bitcoin created on August 1, 2017, by proponents of larger blocks who disagreed with the SegWit scaling approach.
• Block Size War — The multi-year community debate over Bitcoin scaling that culminated in SegWit’s activation and the Bitcoin Cash fork, shaping Bitcoin’s governance culture.
• Ordinals Protocol — A protocol for inscribing arbitrary data on Bitcoin using SegWit’s witness space discount, enabling NFT-like functionality on the Bitcoin blockchain.

FAQ

Q: What does “Segregated Witness” actually mean in plain English?

“Segregated” means separated, and “Witness” refers to the cryptographic signatures that prove a transaction is authorized. So “Segregated Witness” literally means separating the signatures from the main transaction data. The signatures are still included in the block for verification purposes, but they are placed in a separate structure that is counted at a discount when calculating block capacity.

Q: How much do SegWit transactions save on fees compared to legacy transactions?

Savings depend on script types, input and output counts, and fee rate. At a fixed sat/vB rate, a smaller virtual size costs less. Compare wallet estimates for the actual transaction rather than assuming a universal discount.

Q: Is SegWit adoption mandatory for Bitcoin users?

Users can still receive and spend legacy outputs, but old nodes do not enforce all newer consensus rules. SegWit-aware software is needed for proper witness validation and supported spending formats. No current adoption percentage is necessary to use it.

Q: How did SegWit enable the Lightning Network?

Lightning relies on pre-signed transactions referencing funding outputs. SegWit removes witness-based changes to the txid under the required conditions, helping make those references reliable. It does not eliminate all Lightning security or availability risks.

Q: What is the difference between bech32 and bech32m addresses?

On Bitcoin mainnet, version-0 witness addresses begin bc1q and use Bech32. Taproot version-1 addresses begin bc1p and use Bech32m. Bech32m applies to versions 1–16; higher versions have other prefixes and do not automatically represent Taproot. (Source: BIP350 Bech32m address encoding)

Q: Did SegWit solve Bitcoin’s scalability problem?

SegWit improves weight efficiency and supports payment-channel designs, but it does not provide unlimited throughput. Capacity gains depend on transaction composition, and layered systems introduce their own operational trade-offs.

Q: Why do some people criticize SegWit?

Critics have raised several objections. Some argued that a direct block size increase would have been simpler and more effective. Others contended that the soft fork deployment mechanism (using the “anyone-can-spend” trick for backward compatibility) was an inelegant workaround. The Ordinals controversy reignited debate about whether the witness data discount incentivizes non-monetary uses of block space that were not originally intended by SegWit’s designers.

Conclusion

SegWit improves Bitcoin’s transaction design through witness separation and block-weight accounting. Use compatible software and address formats, and assess fees from the actual transaction rather than assuming fixed savings or unlimited capacity.

Further reading on UEEx: Hardware wallet setup; Encryption and cryptography; Protecting crypto from hackers

Sources

BIP141 Segregated Witness

Bitcoin Core SegWit wallet development

BIP350 Bech32m address encoding

BIP144 witness serialization

Ordinal inscription data

Bitcoin Cash May 2024 adaptive block limit