What is SegWit?

Introduction

SegWit is a Bitcoin protocol upgrade that separates signature data from the rest of a transaction. That sounds like a formatting change, but it solved a deeper problem: in Bitcoin’s original design, the part of a transaction that proves authorization was mixed into the same byte string that gave the transaction its identity.

That coupling caused trouble. If a transaction’s identifier changes when its signature encoding changes, then systems built on top of Bitcoin cannot reliably refer to unconfirmed transactions by ID. Wallets can work around some of that. More advanced protocols cannot. SegWit exists because Bitcoin needed a way to keep the meaning of a transaction stable while still allowing signatures to do their job.

Once you see that, the rest of SegWit makes sense. The witness is separated so transaction identity can be defined without it. Blocks commit to that witness separately so the data is still consensus-critical. Block capacity is re-measured so witness bytes are accounted for differently from older transaction bytes. And script versioning is introduced so future upgrades can live inside the same framework. That is why SegWit is both a fix for an old problem and a foundation for later upgrades such as Taproot.

Why was SegWit introduced in Bitcoin?

A Bitcoin transaction does two conceptually different things at once. It names coins being spent and new outputs being created, and it also carries the proofs that the spender is allowed to spend them. In the pre-SegWit design, both of those roles lived inside the same serialized transaction, and the transaction ID, or txid, was the double-SHA-256 hash of that full legacy serialization.

That meant a strange thing: data whose purpose was merely to prove the transaction valid could also change the transaction’s identity. In particular, signatures and script encodings had forms of malleability. Even when nobody changed where the money was going or how much was being paid, small representational changes could produce a different txid. The economic meaning of the transaction stayed the same, but the handle other transactions used to refer to it did not.

This is the key idea to hold on to: Bitcoin had mixed up the transaction’s content with the witness that justifies it. If identity depends on both, then identity can shift for reasons unrelated to payment intent.

That was especially painful for chains of unconfirmed transactions. Suppose Alice creates a transaction that pays Bob, and Bob immediately creates a second transaction spending that unconfirmed output. Bob has to refer to Alice’s transaction by txid. If Alice’s first transaction gets malleated before confirmation, Bob’s child transaction points to the wrong thing and breaks. SegWit’s design goal was to make this kind of nonintentional malleability impossible by ensuring signatures no longer affect the transaction identifier used for dependencies.

There was a second design debt too. The old signature-hashing method forced repeated hashing work across inputs, which made verification scale poorly for some transactions. And there was a third: Bitcoin lacked a clean script versioning mechanism that would let new spending rules be introduced without entangling them with old ones. SegWit addressed all three at once because all three stemmed from the same architectural issue: the authorization data was too tightly bound to the legacy transaction format.

How does SegWit change Bitcoin transactions (txid vs wtxid)?

SegWit introduces a new structure called the witness. The witness contains the data required to validate certain spends, especially scripts and signatures, and it is committed to blocks separately from the old transaction merkle tree. In ordinary terms, the transaction is split into a base part and a witness part.

The base part still contains the version, inputs, outputs, and locktime in the form older nodes understand. The witness part is attached alongside it and contains per-input witness stacks. For transactions without witness data, Bitcoin continues using the old serialization exactly. For transactions with witness data, a new serialization format is used with a marker byte of 0x00, a nonzero flag byte, then inputs, outputs, witness data, and locktime.

That split produces two hashes, and understanding why there are two is central to understanding SegWit. The traditional txid stays defined exactly as before: it is the hash of the old serialization, which does not include witness data. SegWit also defines wtxid, the hash of the new serialization that does include witness data.

This is not redundancy for its own sake. Each ID serves a different invariant. The txid preserves compatibility with existing transaction references, because outpoints in inputs still point to previous outputs using the traditional transaction identifier. The wtxid gives witness-aware software a hash that commits to the entire transaction including signatures. So Bitcoin keeps the old identity where compatibility requires it, while adding a new identity where full accountability requires it.

A simple example makes the distinction concrete. Imagine a transaction spending one SegWit output and creating one new output. Its base data says which previous output is being spent, where the coins are going, and under what locktime rules. Its witness contains a signature and public key proving the spender is authorized. If someone could alter the exact representation of that signature without changing its validity, the wtxid would change, because the full transaction changed. But the txid would not, because the base transaction did not change. That is exactly the point: descendants depending on the transaction’s outputs can still refer to it stably by txid, while upgraded nodes can still commit to and relay the full witness-bearing transaction via wtxid.

How are SegWit witness rules enforced despite legacy nodes?

At first glance, SegWit seems paradoxical. If older nodes do not validate witness data, how can witness rules matter at consensus?

The answer is that SegWit is a soft fork. Old nodes continue to see blocks and transactions in a form they can parse, and upgraded nodes add extra validity rules. The witness is hidden from old transaction IDs and from the legacy merkle tree, but it is not unaccounted for. Each SegWit block must include a commitment to the witness data in the coinbase transaction.

Mechanically, upgraded nodes compute a witness merkle tree whose leaves are the wtxid values of the block’s transactions. The root of that tree is then committed into an [OP_RETURN](https://scribe-topic-id.invalid/protocols.bitcoin.op_return) output in the coinbase transaction, together with a coinbase input witness reserved value. This makes witness data part of what the block commits to under consensus.

So the block effectively carries two commitments. The old merkle root in the block header commits to legacy transaction IDs, preserving compatibility with existing nodes. The coinbase commitment commits to witness-bearing transaction hashes, allowing upgraded nodes to verify the segregated witness data. That is the compatibility trick at the heart of SegWit: new rules are enforced by upgraded nodes without requiring a new block header format.

This also explains an important safety caveat. Pre-SegWit nodes do not validate witness data and generally treat witness programs as anyone-can-spend from their limited point of view. They still accept valid SegWit blocks because those blocks satisfy the old rules plus some additional structure they ignore. But that means non-upgraded software cannot fully enforce the new spending conditions. For ordinary compatibility this is acceptable; for security-sensitive applications, it means relying on old validation logic is insufficient.

What is a SegWit witness program and how does it define outputs?

SegWit does not just move data around. It also defines a new pattern for outputs called a witness program. A script that consists of a one-byte version push followed by a data push of length 2 to 40 bytes gets special meaning. The first pushed value is the witness version; the pushed byte string is the witness program.

This is where SegWit becomes more than a patch. The version byte creates a namespace for future spending rules. Instead of overloading old script behavior forever, Bitcoin can say: version 0 means one set of validation rules, version 1 can later mean another, and so on. That versioning mechanism is one of SegWit’s most durable contributions.

For version 0, BIP141 defines exactly two valid witness program lengths. A 20-byte program means P2WPKH, pay-to-witness-public-key-hash. A 32-byte program means P2WSH, pay-to-witness-script-hash. Other lengths for version 0 fail. Versions 1 through 16 are reserved by BIP141 for future extensions and are not interpreted by that BIP.

The difference between P2WPKH and P2WSH mirrors an older distinction. P2WPKH is the SegWit-native analogue of paying to a public key hash for ordinary single-key payments. P2WSH is the SegWit-native analogue of paying to a script hash when you want more complex scripts. In both cases, the on-chain output can stay compact while the satisfying data appears in the witness when the output is spent.

This can happen either natively or wrapped inside P2SH for compatibility. The wrapped form let older wallets pay SegWit-capable recipients using familiar 3...-style P2SH addresses, but it uses more block space than native witness outputs. Native SegWit outputs became more ergonomic with Bech32 addresses, standardized later for version-0 SegWit outputs. For SegWit v0, native addresses use Bech32; later witness versions such as Taproot’s v1 use Bech32m rather than Bech32.

How did SegWit change signature hashing (BIP143) and why it matters?

Moving signatures into the witness gets most of the attention, but SegWit also changed how signatures for version-0 witness programs are hashed and verified. This is specified in BIP143.

The old digest algorithm had two practical weaknesses. First, it repeated hashing work in a way that could make total verification cost grow quadratically in some cases. Second, the signature preimage did not commit to the amount being spent by the input, which made secure offline signing harder because a signer needed reliable external information about the UTXO amount.

BIP143 fixes both by defining a new digest algorithm for SegWit v0 inputs. Instead of reconstructing and hashing large overlapping chunks separately for every signature, it computes reusable aggregate hashes such as hashPrevouts, hashSequence, and hashOutputs. Those values can be reused across inputs in the same transaction, reducing hashing complexity from O(n^2) to O(n) for relevant cases.

Just as importantly, the digest includes the value of the output being spent. That means a hardware signer or air-gapped device can sign safely as long as it is told the amount and script being spent; if that information is wrong, the signature simply will not validate on-chain. This is a subtle but important improvement in signing safety.

A useful way to think about BIP143 is that SegWit did not merely relocate signatures. It also took the opportunity to define cleaner semantics for what a signature is actually authorizing in witness version 0 scripts.

How does SegWit’s block weight model work and how does it affect fees?

Many people first encountered SegWit through the claim that it increased Bitcoin’s capacity. That is true, but it is easy to misunderstand the mechanism if you start there.

SegWit does not simply replace the 1 MB block size limit with a flat 4 MB limit. Instead it introduces block weight, defined as base size * 3 + total size, with a consensus rule that block weight must be at most 4,000,000. Here, base size is the block size without witness data, and total size is the full size including witness.

This formula means each non-witness byte effectively counts four weight units, while each witness byte counts one. In practice, witness data receives a discount relative to old-style data. That discount is not arbitrary. It reflects the design judgment that signatures are necessary for validation but are less central than the UTXO-defining core of the transaction for many long-term network costs.

The consequence is that moving signatures into the witness can reduce a transaction’s fee burden when fees are quoted in virtual bytes, or vsize, which is derived from weight. Wallets therefore estimate SegWit transaction fees using virtual size rather than raw serialized bytes. A transaction with lots of signature material becomes cheaper relative to a legacy transaction with the same economic effect.

The weight model also helped keep SegWit compatible as a soft fork. Legacy nodes still see a block structure that looks valid under old parsing rules, while upgraded nodes enforce the new weight accounting. In broad terms, SegWit increased effective usable capacity, especially when transactions make heavy use of witness data, without redefining the block header or breaking old transaction references.

There are tradeoffs here. More effective capacity can increase bandwidth and validation work, and widespread use of SegWit changes the shape of block propagation costs rather than making them disappear. But the accounting is more nuanced than “Bitcoin blocks became four times larger.” The protocol distinguishes between bytes that define the spendable state and bytes that mainly prove authorization.

How are SegWit transactions and blocks relayed across the Bitcoin network?

Consensus changes alone are not enough; nodes need a way to relay SegWit transactions and blocks. BIP144 defines the peer-to-peer changes that make this work.

The network serialization for witness-bearing transactions includes the marker and flag fields so upgraded parsers can distinguish the witness format from the old format. Each input then has a corresponding witness field encoded as a stack of byte arrays. If the witness is empty, implementations must use the old serialization, not the new one. That rule avoids needless ambiguity and preserves exact legacy behavior when no witness exists.

Nodes advertise witness capability with the NODE_WITNESS service bit. They can request witness-bearing transactions and blocks using witness-specific getdata types, while normal inventory announcements continue using the traditional transaction and block types. This is a careful compatibility design: old nodes are not forced to understand new inventory semantics, while upgraded nodes can still request full witness data when needed.

The pattern matches SegWit’s broader philosophy. Preserve old interfaces where compatibility depends on them; add parallel witness-aware machinery where correctness requires it.

What practical benefits does SegWit give users (addresses, lower fees, Lightning, Taproot)?

At the user level, SegWit is most visible through address types and lower fees for equivalent spends. A wallet using P2SH-wrapped SegWit may generate addresses beginning with 3. A wallet using native SegWit v0 generates Bech32 addresses. Those formats represent outputs whose spending data will live partly or wholly in the witness, which usually means more fee-efficient spending than legacy equivalents.

At the protocol level, the most important use is less visible: stable unconfirmed transaction dependency. Because witness changes no longer alter the txid, protocols that build chains of unconfirmed transactions became much more practical. This is why SegWit is often described as a prerequisite for the Lightning Network. Lightning relies on constructing and exchanging transactions whose safety depends on transaction identities remaining stable before confirmation.

SegWit also provided the upgrade surface used later by Taproot. Taproot is defined as a SegWit version 1 output type with a 32-byte witness program. That relationship is not incidental. SegWit’s witness-version design created a clean place for new spending rules to live. Taproot’s key-path and script-path spends, new witness structure, and address encoding via Bech32m all sit inside the extension framework SegWit introduced.

This is one of the clearest signs that SegWit was a platform change, not merely a bug fix. It repaired malleability, improved fee accounting, and established the script versioning model Bitcoin now uses for major upgrades.

What limitations and compatibility risks does SegWit have?

SegWit’s compatibility comes with limits. Old nodes still accept SegWit-valid blocks, but they do not validate witness data. That is acceptable only because upgraded miner and fully validating nodes enforce the extra rules. If too much of the ecosystem stayed non-upgraded during or after activation, users depending on the new rules could face safety issues. This is the normal shape of soft-fork compatibility: backward recognition is not the same as full validation.

Wallets also need to handle witness versions carefully. In BIP141, version 0 has tightly specified lengths and semantics. Versions 1 through 16 are reserved there for future use, which means software must not assume every witness program behaves like v0. Later upgrades such as Taproot rely on exactly that distinction.

Address handling turned out to have its own lessons. Native SegWit v0 addresses use Bech32, but later analysis found checksum issues relevant to future witness versions, which led to Bech32m for v1 and above. That is not a flaw in SegWit’s witness model itself, but it shows something important: once a protocol adds versioning hooks for future upgrades, surrounding tooling such as address encodings must also be version-aware in a disciplined way.

There are also practical implementation hazards. Using uncompressed public keys in contexts intended for SegWit v0 is discouraged and can create interoperability or future-compatibility risks. Fee estimation must use virtual size rather than raw bytes. Wallets, hardware signers, relays, miners, and block template software all needed updates for SegWit to work correctly in practice. The conceptual idea is clean; the ecosystem migration was necessarily detailed.

Why is SegWit an architectural change for Bitcoin?

The lasting importance of SegWit is architectural. It changed what counts as the stable core of a Bitcoin transaction.

Before SegWit, the transaction’s identity and its authorization proof were entangled. After SegWit, Bitcoin treats them as related but distinct objects. The base transaction defines the state transition other transactions depend on. The witness proves that transition is authorized. Consensus still commits to both, but it no longer has to identify the transaction by the same bytes that carry malleable signature material.

That separation gave Bitcoin room to improve multiple things at once. It reduced nonintentional malleability. It introduced better signature hashing for v0 witness programs. It changed capacity accounting from raw size to weight. It added witness-versioned outputs that later upgrades could reuse. And it did all that through a soft fork that older nodes could continue to parse.

If you want the shortest accurate memory of SegWit, it is this: **SegWit taught Bitcoin to separate “what this transaction does” from “how we prove it is allowed.” ** Once that separation existed, several long-standing problems became easier to solve, and future upgrades had a cleaner place to attach.

How do you get exposure to Bitcoin after studying SegWit?

Get practical exposure to Bitcoin by buying BTC on Cube and optionally withdrawing to your own wallet. The Cube workflow keeps trading and settlement on the platform: fund your account, place an order on the BTC market, then withdraw on-chain if you prefer self-custody.

1. Deposit fiat (USD/EUR) via Cube’s on-ramp or transfer a supported stablecoin (USDC) into your Cube account.
2. Open the BTC/USD or BTC/USDC market on Cube. Choose a limit order for precise execution or a market order for immediate fill.
3. Enter the BTC amount or the fiat you want to spend, review estimated fees and the order preview, then submit the order.
4. If you want to hold off-exchange, withdraw BTC to your Bech32 address and wait for on-chain confirmations (commonly 3+ confirmations for strong finality) before considering the transfer settled.