What Is SegWit? Bitcoin’s Segregated Witness Explained

SegWit is short for Segregated Witness, a Bitcoin protocol upgrade that changed where transaction authorization data is carried and how block capacity is measured. Activated in August 2017, it is often described as a block-size increase, but that shorthand misses the more important design change: signatures moved into a separate witness structure. That helped solve transaction malleability and made some second-layer designs practical. It also introduced a different way to weigh transaction data, not a simple four-megabyte limit.

The problem SegWit was designed to solve

In Bitcoin’s original transaction format, the unlocking data—including signatures—sat inside the transaction structure used to calculate its transaction ID, or txid. A txid is the identifier other transactions use when they refer to a payment. But ECDSA signatures can have more than one valid encoding. Before confirmation, a third party could sometimes alter signature data without changing what the transaction authorized, producing a different txid for a payment with the same economic effect. This is transaction malleability.

That mattered most to software that built a chain of dependent transactions before the first one confirmed. If a later transaction referred to the original txid and that identifier changed, the later transaction could refer to an output that no longer appeared under that name. SegWit did not prevent every possible form of malleability in every transaction; it removed the signature-related source for spends that use SegWit inputs. The distinction matters: a transaction that still includes legacy inputs can retain legacy malleability concerns.

What “segregated witness” means

A witness is the data needed to prove that a transaction input may be spent—usually a signature and public key for a common single-key payment. SegWit places that data in a witness field, distinct from the traditional transaction serialization. The network still validates the witness: it is committed to the block through a witness hash commitment in the coinbase transaction. “Separate” does not mean optional for consensus or ignored by upgraded nodes.

A SegWit transaction therefore has two useful identifiers. The txid is calculated from the traditional transaction data without the witness. The wtxid includes the witness serialization. The txid is what dependent transactions reference, while the wtxid distinguishes the full serialized versions. Legacy transactions have no witness data and, in that case, their txid and wtxid are the same.

Why it is a soft fork

SegWit was activated as a soft fork: older nodes could continue operating under the rules they already understood, while upgraded nodes enforced additional witness rules. The new witness programs were designed so legacy software would see outputs in a compatible way, even though it could not fully validate the new witness data. Upgraded miners and nodes enforce the stricter rules.

Bitcoin’s 2017 scaling debate included competing proposals, but SegWit itself did not split the chain. Bitcoin Cash launched separately in August 2017 after a hard fork; SegWit2x, a later proposal to pair SegWit with a larger base block size, was cancelled in November 2017. Keeping those events distinct helps explain why people sometimes conflate SegWit with a hard fork that it was not.

Block weight, not a four-megabyte block

SegWit replaced the old one-megabyte block-size rule with a block-weight calculation. In the BIP 141 formula, block weight equals three times base size plus total size. Because non-witness data is counted in both base and total, it effectively costs four weight units per byte. Witness data is counted only in total size, so it costs one unit per byte. The maximum block weight is four million units.

This creates a discount for witness data. It does not mean a real-world block may always hold exactly four megabytes of transactions: the non-witness portion still consumes most or all of the traditional one-megabyte base budget. Maximum raw size depends on the transaction mix, and typical capacity is not one fixed byte count.

How SegWit can affect transaction fees

Fees are commonly quoted per virtual byte, or vbyte. A transaction’s weight divided by four, rounded up, gives its virtual size. Since witness bytes carry less weight than non-witness bytes, a SegWit spend can have a lower virtual size than an otherwise similar legacy spend. At the same satoshis-per-vbyte rate, that can lower the fee.

But “SegWit is cheaper” is not a promise about every payment. The fee depends on the transaction’s inputs and outputs, wallet construction, current fee market and address type. A bc1q receive address does not change the fee paid by the sender; the savings appear when spending coins from SegWit outputs. Batching can matter more than the address format for some transactions.

P2SH-wrapped and native SegWit addresses

The first common SegWit addresses you may see start with “3”. These are P2SH-wrapped SegWit: the witness program is placed inside the older pay-to-script-hash format. That helped wallets and services adopt SegWit gradually, but adds a little overhead compared with native SegWit.

Native version-zero SegWit addresses use Bech32 and begin with “bc1q” on Bitcoin mainnet. Bech32 uses a checksum designed to detect common transcription mistakes. It is not a guarantee that a pasted address is the intended recipient, so users should still confirm the address and network before sending. Taproot addresses start “bc1p” and use Bech32m, a related format for witness version one.

The connection to Lightning

Lightning channels rely on pre-signed transactions that can be broadcast if needed. Before SegWit, malleability made it harder to safely build a chain of transactions around an unconfirmed funding payment. SegWit’s txid change addressed that specific problem for SegWit spends, while its new signature-hash rules also improved verification mechanics. That was a major enabling step for Lightning, though Lightning’s operation depends on much more than SegWit alone.

What SegWit did not do

SegWit did not make Bitcoin transactions instant, eliminate fees or guarantee a particular block capacity. It did not make all transactions non-malleable: legacy inputs and other edge cases remain relevant. Nor did it create the Lightning Network by itself. It supplied protocol changes that made some dependent transaction designs more reliable.

How to recognize SegWit use

For an ordinary wallet user, the address format is a practical clue. A Bitcoin mainnet address beginning “bc1q” is a native version-zero SegWit address; a “3” address may be either wrapped SegWit or another P2SH script, so the prefix alone cannot prove which. A “bc1p” address is Taproot, not version-zero SegWit. Older “1” addresses are legacy P2PKH.

At a network level, Glassnode reported that on October 29, 2026, 97.353% of Bitcoin transactions spent at least one SegWit input, while input-level utilization was 91.864%. Those are different measures, not the percentage of wallets or users: the transaction statistic counts each transaction once if it spends at least one such input, whereas utilization counts SegWit inputs. A transaction with mixed inputs contributes to the first measure even if some inputs remain legacy.

The useful way to think about SegWit

Think of SegWit as two related upgrades: a transaction-format change that separated authorization data from the txid, and a block-accounting change that prices witness bytes differently. The first improved the reliability of dependent transactions; the second increased usable block capacity without imposing a fixed four-megabyte byte limit. Its address formats made the new spend types practical for wallets, and its design remains part of how Bitcoin transactions work today.