Bitcoin’s scalability has long been one of its most pressing challenges. As transaction volume grows, the network faces congestion, leading to slower confirmations and higher fees. While solutions like the Lightning Network promise off-chain scalability, they depend on foundational upgrades within Bitcoin’s core protocol. One such pivotal upgrade is Segregated Witness (SegWit) — a soft fork that not only improves transaction efficiency but also resolves critical technical flaws.
In this comprehensive guide, we’ll explore how SegWit works, examine real-world transaction structures, and analyze its benefits and controversies — all while keeping the original depth and technical accuracy intact.
What Is Segregated Witness (SegWit)?
Segregated Witness, commonly known as SegWit, is a protocol upgrade defined by several Bitcoin Improvement Proposals (BIPs), including BIP-141, BIP-142, BIP-143, BIP-144, and BIP-145. Its primary goal is to enhance Bitcoin's scalability and security by reorganizing transaction data.
At its core, SegWit separates ("segregates") the witness data — digital signatures used to verify ownership — from the main transaction body. These signatures, also called scriptSig, unlocking scripts, or witness, are moved into a separate structure within the block.
This simple yet powerful change brings multiple benefits:
- Reduces transaction size
- Solves transaction malleability
- Enables advanced layer-2 solutions like the Lightning Network
- Lowers transaction fees
👉 Discover how SegWit powers next-gen Bitcoin transactions — explore tools that support it today.
How Does Bitcoin Handle Transactions?
Before diving into SegWit, it's essential to understand Bitcoin’s transaction model.
Unlike traditional banking systems that track account balances, Bitcoin uses a UTXO (Unspent Transaction Output) model. Each user’s balance is derived from a chain of incoming transactions.
A typical Bitcoin transaction consists of:
- Inputs: References to previous UTXOs you want to spend
- Outputs: New UTXOs sent to recipient addresses
Each output includes:
scriptPubKey(locking script): Defines conditions for spendingscriptSig(unlocking script): Contains proof of ownership (signatures)
For example, in a Pay-to-Public-Key-Hash (P2PKH) transaction:
OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIGTo spend this output, the sender must provide a valid signature and public key matching the hash.
The Problem: Transaction Malleability
One major flaw in pre-SegWit Bitcoin was transaction malleability — the ability for third parties to alter transaction IDs without invalidating them.
Since transaction IDs (txids) are hashes of the entire transaction data — including signatures — any change to the signature alters the txid. Malicious actors could slightly modify signature encodings, changing the txid while keeping the transaction valid.
This posed serious risks:
- Broke chains of unconfirmed transactions
- Compromised payment channels
- Prevented reliable implementation of Lightning Network
SegWit fixes this by removing signatures from the transaction data used to compute txids. Instead, it introduces a new identifier: wtxid, which includes both the base transaction and the witness data.
Now, changes to witness data don’t affect the base txid — solving malleability once and for all.
How SegWit Works: A Technical Breakdown
Pay-to-Witness-Public-Key-Hash (P2WPKH)
Let’s compare traditional P2PKH with its SegWit counterpart.
Traditional P2PKH Output
"scriptPubKey": "OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG"SegWit P2WPKH Output
"scriptPubKey": "0 <20-byte-hash>"The new format is simpler:
0= version number (witness program version)<20-byte-hash>= RIPEMD160(SHA256(public key))
When spending:
scriptSigremains empty- Signatures go into the witness field
"vin": [{
"txid": "abc...",
"vout": 0,
"scriptSig": ""
}],
"witness": ["<signature>", "<pubkey>"]Legacy nodes see this as a valid anyone-can-spend output (due to empty scriptSig), but upgraded nodes enforce strict verification using the witness data.
Important Warning
Legacy wallets cannot safely spend from SegWit outputs. Attempting to do so with an empty signature results in rejection by modern nodes. Additionally, only compressed public keys should be used when creating SegWit addresses — otherwise, funds may become irrecoverable.
Pay-to-Witness-Script-Hash (P2WSH)
For complex scripts like multi-signature wallets, SegWit introduces P2WSH.
Standard P2SH Output
"scriptPubKey": "HASH160 <hash-of-redeem-script> EQUAL"To spend:
- Provide redeem script + required signatures in
scriptSig
With P2WSH:
"scriptPubKey": "0 <32-byte-SHA256-hash>"Spending structure:
"scriptSig": "",
"witness": ["<signature1>", "<signature2>", "<redeem-script>"]This moves bulky script data off-chain from the main transaction, reducing on-chain footprint significantly.
Backward Compatibility: Nested SegWit (P2SH-P2WPKH / P2SH-P2WSH)
Not all users upgraded immediately. To ensure compatibility, SegWit supports nested transactions inside P2SH addresses.
Example Scenario
Alice wants to send BTC to Bob. Bob uses a SegWit wallet; Alice does not.
Bob generates a P2SH address that embeds a SegWit script. To Alice, it looks like a normal P2SH address. But when Bob spends it, he enjoys lower fees thanks to SegWit’s efficiency.
P2SH(P2WPKH) Workflow
- Create witness program:
0 <pubkey-hash> - Hash it:
HASH160(0 <pubkey-hash>) - Generate P2SH address: e.g.,
37Lx99uaGn5avKBxiW26HjedQE3LrDCZru
Spending:
"scriptSig": "0 <pubkey-hash>",
"witness": ["<sig>", "<pubkey>"]This allows gradual adoption without disrupting existing infrastructure.
Key Benefits of SegWit
✅ Eliminates Transaction Malleability
By decoupling signatures from txid calculation, SegWit ensures transaction IDs remain stable — enabling safe construction of payment channels and second-layer protocols.
✅ Increases Block Capacity & Reduces Fees
SegWit introduces virtual size (vSize) for fee calculation:
- Witness data counts at only 25% weight
- Base transaction data counts at 100%
Example:
- Legacy 200-byte transaction → fits ~5,000 per 1MB block
- Equivalent SegWit tx: 80 bytes base + 120 bytes witness
→ vSize = 80 + (120 × 0.25) = 110 bytes
→ Fits ~9,090 per block — ~80% more capacity
With fee rates at 40 satoshis/byte:
- Legacy cost: 200 × 40 = 8,000 satoshis
- SegWit cost: 110 × 40 = 4,400 satoshis (~45% cheaper)
✅ Improves Signature Verification Efficiency
Before SegWit, signature verification complexity grew quadratically — O(n²) — due to repeated hashing in multi-signature scripts.
SegWit optimizes this to O(n) linear complexity by caching message hashes. This drastically reduces CPU load during validation, improving node performance and network scalability.
✅ Enables Script Versioning
Each witness program starts with a version byte (e.g., 0). This allows future upgrades via soft forks — enabling new features like Taproot (BIP-340) without breaking compatibility.
Taproot itself builds on SegWit foundations to enable private smart contracts and batched signatures.
Frequently Asked Questions (FAQ)
Q: What is transaction malleability, and why does it matter?
A: It's the ability to alter a transaction ID without invalidating it. This breaks dependent transactions and prevents reliable off-chain scaling like Lightning Network. SegWit solves it by isolating signatures.
Q: Can I use SegWit without upgrading my wallet?
A: No. You need a SegWit-compatible wallet to receive or spend from native or nested SegWit addresses. Sending to a SegWit address from an old wallet may still work if it's nested in P2SH.
Q: Are there different types of SegWit addresses?
A: Yes:
- P2WPKH (bech32): Starts with
bc1q— native SegWit - P2SH-P2WPKH: Starts with
3— backward compatible - P2WSH / P2SH-P2WSH: For complex scripts like multisig
Q: Is SegWit safe? Could it compromise funds?
A: Yes — if misused. Using uncompressed public keys or incorrect formats may lock funds permanently. Always use modern wallets that handle these details securely.
Q: Does SegWit increase block size beyond 1MB?
A: Not technically. But with block weight capped at 4 million units (where witness data weighs less), effective capacity increases to ~1.7–2MB equivalent.
Q: Why did some people oppose SegWit?
A: Critics argued it was too complex, delayed true scaling (like bigger blocks), and risked centralization by reducing full-node viability. However, it remains widely adopted today.
Challenges and Criticisms
Despite its advantages, SegWit isn't perfect:
- Incomplete adoption: Non-SegWit UTXOs still exist, leaving parts of the network vulnerable to malleability.
- Verification burden: Full nodes must validate witness data separately; lightweight clients skip it.
- Irreversibility: Removing SegWit would render all SegWit outputs unspendable.
- Code complexity: Large-scale changes increase bug risk and maintenance load.
Still, most experts agree that SegWit was necessary to unlock Bitcoin’s next phase of innovation.
Conclusion
Segregated Witness represents one of Bitcoin’s most impactful upgrades. By rethinking how transaction data is structured, it solved long-standing issues like malleability, improved scalability, reduced fees, and laid the foundation for future advancements like Taproot and the Lightning Network.
While not without controversy, its widespread adoption proves its value in practice. For developers, investors, and everyday users alike, understanding SegWit is essential to navigating Bitcoin’s evolving ecosystem.
Whether you're building on layer-2 networks or simply sending BTC more efficiently, SegWit plays a crucial role behind the scenes.