What is SegWit?

Introduction

SegWit, or Segregated Witness, was one of the most important upgrades to the Bitcoin protocol, activated in 2017. Understanding SegWit is fundamental to understand how Bitcoin evolves, how technical problems are solved, and how improvements are implemented without breaking compatibility. This guide will explain what SegWit is, how it fixes malleability, how it allows larger blocks, and its impact on Bitcoin.

Important: This is an advanced level guide. We assume basic knowledge of Bitcoin transactions, scripts, block structure, and technical concepts. If you're a beginner, we recommend first understanding Bitcoin basics before advancing to this technical content about SegWit.

By the end of this guide, you'll understand how SegWit works, how it fixes transaction malleability, how it allows more transactions per block, and why it was a fundamental upgrade for Bitcoin.

What Is SegWit?

Basic Concept

SegWit (Segregated Witness) is a Bitcoin protocol upgrade that separates signature data (witness) from main transaction body.

Fundamental change:

Before: Signatures were inside transaction inputs
After: Signatures (witness) are separated and don't count in base size
Result: More transactions fit per block, malleability fix

Characteristics:

Soft fork (compatible with previous versions)
Doesn't break old transactions
Adds new transaction types
Improves security and efficiency

Activation:

Proposed in BIP 141, 143, 144, 145
Activated August 2017 (block 481,824)
Soft fork through miner signaling

Why Was SegWit Created?

Problems SegWit solves:

1. Transaction Malleability:

Transactions could be altered without invalidating signature
Transaction ID could change even if valid
Problem for Lightning Network and other applications

2. Block Size Limit:

1 MB block was rigid limit
Many transactions didn't fit
High fees during congestion periods

3. Space Optimization:

Signatures occupied significant space
Didn't need to be in main body
Separation allows optimization

Malleability Fix

What Is Malleability?

Transaction malleability is ability to alter transaction ID without invalidating signature.

Problem:

Attacker could alter signature (serialization)
Transaction ID changed
Transaction still valid
Confusion and problems for applications

Example:

You send transaction
ID is: abc123...
Someone intercepts and modifies serialization
ID changes to: xyz789...
Transaction still valid
You don't know which ID is correct

How SegWit Fixes Malleability?

Witness Separation:

Before (legacy):

Signature was in ScriptSig inside input
ScriptSig was part of transaction body
Could be altered without invalidating transaction
Transaction ID was calculated including signature

After (SegWit):

Signature (witness) is separated from body
Transaction ID is calculated WITHOUT witness
Witness cannot alter transaction ID
ID is immutable after creation

TXID Formula:

Before (legacy):

TXID = SHA-256d(complete_transaction_including_signatures)

After (SegWit):

TXID = SHA-256d(transaction_without_witness)
Witness stays separate and doesn't affect TXID

Result:

✅ TXID is immutable
✅ Cannot be altered without invalidating transaction
✅ Malleability fixed
✅ Foundation for Lightning Network

Comparison: Before vs After

Before (legacy):

Transaction:
  - Inputs:
      - ScriptSig (with signature) ← Part of TXID
  - Outputs
  - Locktime

TXID = hash of everything including signatures
Problem: Signature can be altered, TXID changes

After (SegWit):

Transaction:
  - Inputs:
      - ScriptSig (empty or minimal)
  - Outputs
  - Locktime

Witness (separated):
  - Signatures for each input

TXID = hash of transaction WITHOUT witness
Solution: TXID doesn't change even if witness changes

Why Was Malleability a Problem?

Practical problems:

1. Lightning Network:

Needs stable TXID to work
Malleability broke Lightning contracts
SegWit solves fundamental problem

2. Applications:

Applications tracking transactions
Confusion about which TXID is valid
Reconciliation problems

3. Security:

Attacker could create confusion
Potential denial of service
Reduced trust

Larger Blocks: More Transactions

How SegWit Allows More Transactions?

Weight Units (WU) Concept:

Before (legacy):

Maximum size: 1 MB (1,000,000 bytes)
Each byte counts equally
Rigid and small limit

After (SegWit):

Limit: 4 million Weight Units (WU)
Base data: 1 WU per byte
Witness data: 1 WU per 4 bytes
Effective limit: ~4 MB for witness + 1 MB base = ~4 MB total

Simplified formula:

Base_Size + (Witness_Size / 4) ≤ 4,000,000 WU

What this means:

Witness data "costs less" in limit
More witness can be included
More transactions fit per block
Effective limit increases

Practical Comparison

Before (legacy - 1 MB block):

Typical block:
- Size: 1,000,000 bytes
- Average transactions: ~2,000 transactions
- High fees when congested
- Rigid limit

After (SegWit - 4 MWU block):

Typical block with SegWit:
- Weight: ~4,000,000 WU
- Equivalent size: ~1.3-2 MB (depends on mix)
- Average transactions: ~3,000-4,000 transactions
- More capacity, lower fees
- Flexible limit based on weight

Capacity increase:

Approximately 2-3x more transactions
Depends on percentage of SegWit transactions
More SegWit = greater capacity

Calculation Examples

Example 1: Legacy Transaction:

Base size: 250 bytes
Witness: 0 bytes (doesn't have it, is legacy)
Weight = 250 × 4 = 1000 WU

Contributes 250 bytes to 4 MWU limit

Example 2: SegWit P2WPKH Transaction:

Base size: 100 bytes
Witness: 108 bytes
Weight = 100 × 4 + 108 = 400 + 108 = 508 WU

But only occupies ~150 effective bytes in limit!

SegWit advantage:

SegWit transaction occupies less space in limit
Allows more transactions per block
More efficient

Effective Block Limit

Simplified calculation:

If block has only legacy transactions:

Limit: 1 MB (as before)
No improvement

If block has only SegWit transactions:

Limit: ~4 MB (witness separated)
Maximum efficiency

Real block (mix):

Usually ~1.5-2.5 MB effective
Depends on SegWit percentage
Significant improvement even with mix

Approximate formula:

Effective_Size ≈ 1 MB + (SegWit_Percentage × 3 MB)

Example: If 50% transactions are SegWit:

Effective_Size ≈ 1 + (0.5 × 3) = 2.5 MB

SegWit Impact

Technical Impact

1. Malleability Fix:

✅ Immutable TXID
✅ Foundation for Lightning Network
✅ Better for applications

2. Increased Capacity:

✅ ~2-3x more transactions per block
✅ Lower fees in normal periods
✅ Better throughput

3. Preparation for Upgrades:

✅ Foundation for Taproot
✅ Allows new script types
✅ Flexibility for future

Economic Impact

1. Fees:

Average fees dropped after SegWit
More transactions per block = less competition
Savings for users

2. Throughput:

Network processes more transactions
Less congestion
Better experience

3. Adoption:

Gradual adoption over years
Majority of transactions now use SegWit
Broad wallet support

Network Impact

1. Security:

Malleability fixed
More solid foundation
Preparation for upgrades

2. Scalability:

Increased capacity
Preparation for growth
Better for adoption

3. Development:

Enables Lightning Network
Enables other upgrades
Foundation for innovation

SegWit Transaction Types

P2WPKH (Pay to Witness Public Key Hash)

Structure:

Before (P2PKH legacy):

ScriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
ScriptSig: <signature> <publicKey>

After (P2WPKH SegWit):

ScriptPubKey: OP_0 <20 bytes: witnessPubKeyHash>
ScriptSig: (empty)
Witness: <signature> <publicKey>

Advantages:

Witness separated
Immutable TXID
Smaller size in limit
Lower fees

P2WSH (Pay to Witness Script Hash)

Structure:

Before (P2SH legacy):

ScriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL
ScriptSig: <redeemScript> <signatures...>

After (P2WSH SegWit):

ScriptPubKey: OP_0 <32 bytes: witnessScriptHash>
ScriptSig: (empty)
Witness: <redeemScript> <signatures...>

Advantages:

Complex scripts with separated witness
More efficient multisig
Immutable TXID

P2SH-Wrapped SegWit

Compatibility:

Structure:

ScriptPubKey: OP_HASH160 <witness_script_hash> OP_EQUAL (normal P2SH)
ScriptSig: <witness_script>
Witness: <signatures...>

Advantage:

Addresses start with "3" (compatible with P2SH)
Works on old wallets
Gradual transition

Native SegWit (Bech32)

Bech32 Addresses:

Start with "bc1"
More efficient format
Better error detection
Direct SegWit support

Example:

Legacy: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
P2SH: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
Native SegWit: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Comparison: Before vs After

Transaction Structure

Before (Legacy):

Legacy Transaction:
├── Version
├── Inputs:
│   └── ScriptSig (with signature) ← Part of TXID
├── Outputs:
│   └── ScriptPubKey
└── Locktime

Size: All bytes count equally
Limit: Rigid 1 MB
TXID: Calculated with signatures (malleable)

After (SegWit):

SegWit Transaction:
├── Version
├── Marker (0x00)
├── Flag (0x01)
├── Inputs:
│   └── ScriptSig (empty or minimal)
├── Outputs:
│   └── ScriptPubKey (OP_0 <hash>)
└── Locktime

Witness (separated):
└── Witness for each input
    └── Signatures

Size: Weight Units (WU)
Limit: 4 MWU (~2-4 MB effective)
TXID: Calculated WITHOUT witness (immutable)

Size Impact

Size comparison:

P2PKH Transaction:

Legacy:

Total size: ~250 bytes
All bytes count: 250 bytes in limit

SegWit P2WPKH:

Base size: ~100 bytes
Witness: ~108 bytes
Weight: 100×4 + 108 = 508 WU
Equivalent to: ~127 bytes in 4 MWU limit
Reduction: ~50% in limit!

2-of-3 Multisig Transaction:

Legacy:

Total size: ~340 bytes
All bytes count: 340 bytes

SegWit P2WSH:

Base size: ~100 bytes
Witness: ~280 bytes
Weight: 100×4 + 280 = 680 WU
Equivalent to: ~170 bytes in limit
Reduction: ~50% in limit!

Block Impact

Legacy Block (1 MB):

Size: exactly 1,000,000 bytes
Transactions: ~2,000 typical transactions
Capacity: limited and rigid

SegWit Block (4 MWU):

Weight: up to 4,000,000 WU
Equivalent size: ~1.5-2.5 MB (depends on mix)
Transactions: ~3,000-4,000 typical transactions
Capacity: increased and flexible

Improvement: 2-3x more capacity depending on SegWit adoption

Fee Impact

Before (Legacy only):

Rigid 1 MB limit
Frequent congestion
High fees at peaks
~2,000 transactions per block

After (with SegWit):

Flexible limit up to ~4 MB
Less congestion
Lower fees
~3,000-4,000 transactions per block

Practical result:

Average fees dropped after SegWit
More transactions processed
Better user experience

Soft Fork: Compatibility

Why Soft Fork?

Soft fork:

Compatible with previous versions
Old nodes still work
Doesn't break existing network
Gradual activation

How it works:

Old nodes see SegWit transactions as "anyone can spend"
New nodes validate correctly
Network works with mix of nodes
Gradual transition possible

SegWit Activation

Activation process:

1. Proposal (BIPs):

BIP 141: SegWit definition
BIP 143: Witness validation
BIP 144: Network and serialization
BIP 145: getblocktemplate

2. Implementation:

Code developed in Bitcoin Core
Extensive testing
Community review

3. Signaling:

Miners signal support
Special block marks activation
Activates when majority signals

4. Activation:

Block 481,824 (August 2017)
SegWit active from this block
New SegWit transactions possible

Compatibility

Coexistence:

Legacy Transactions:

Continue working
Old nodes still validate
No changes needed
Can coexist indefinitely

SegWit Transactions:

New functionalities
New nodes validate correctly
Old nodes don't validate, but accept
Coexistence possible

Result:

✅ No compatibility break
✅ Gradual transition
✅ Optional adoption
✅ Network continues functioning

Adoption and Current Status

Adoption Rate

Evolution:

2017 (activation): ~0% SegWit transactions
2018: ~30% transactions
2019: ~50% transactions
2020-2024: ~70-90% transactions
Trend: Growing adoption over time

Why gradual adoption?:

Wallets need to update
Users need to migrate
Legacy compatibility allows slow transition
Natural adoption process

Adoption Benefits

For users:

Lower fees
Faster transactions (less congestion)
Better experience
Preparation for Lightning Network

For network:

More capacity
Less congestion
Foundation for future upgrades
Greater scalability

For developers:

Malleability fixed
Foundation for Lightning Network
New script types possible
Greater flexibility

SegWit and Lightning Network

Relationship with Lightning

Dependency:

Lightning Network requires SegWit
Fixed malleability is fundamental
Immutable TXID is necessary
Essential technical foundation

Why necessary?:

Lightning uses contracts depending on TXID
Malleability would break contracts
SegWit fixes fundamental problem
Allows Lightning to work correctly

Result:

SegWit prepared ground for Lightning
Lightning Network possible after SegWit
Upgrades together create more value
More robust ecosystem

Limitations and Considerations

SegWit Limitations

1. Gradual Adoption:

Not everyone uses SegWit immediately
Benefits increase with adoption
Process takes time

2. Legacy Compatibility:

Old wallets don't support
Migration necessary
May confuse users

3. Limit Still Exists:

Doesn't remove limit completely
Only increases capacity
Doesn't solve all scalability problems

Considerations

1. Not Complete Solution:

SegWit increases capacity, doesn't solve everything
Other solutions still necessary (Lightning, etc.)
Part of set of improvements

2. Adoption Is Important:

Benefits depend on adoption
More adoption = more benefits
Incentives to migrate

3. Foundation for Future:

SegWit prepares for future upgrades
Taproot depends on SegWit
Foundation for innovation

Comparison with Other Solutions

SegWit vs Direct Block Size Increase

Direct increase (hard fork):

Would change maximum size directly
Would require hard fork
Simpler conceptually
But more divisive

SegWit (soft fork):

Increases capacity through weight
Soft fork (compatible)
More complex, but safer
Gradual adoption possible

SegWit advantage:

✅ Soft fork (no division)
✅ Fixes malleability
✅ Preparation for future
✅ Safer and more stable

SegWit vs Taproot

SegWit (2017):

Separates witness
Fixes malleability
Increases capacity
Foundation for upgrades

Taproot (2021):

Uses SegWit as foundation
Improves privacy
Schnorr signatures
Complementary upgrade

Relationship:

SegWit prepares ground for Taproot
Taproot depends on SegWit
Both work together
Incremental evolution

Frequently Asked Questions

Does SegWit increase block size?

Technically doesn't increase 1 MB limit directly. But allows more transactions through weight units. Effective limit can be ~2-4 MB depending on transaction mix.

Do all transactions need to use SegWit?

No. Legacy transactions continue working. SegWit is optional. But using SegWit brings benefits (lower fees, etc.).

Does SegWit break compatibility?

No. SegWit is soft fork. Legacy transactions continue working. Old nodes still validate. Total compatibility maintained.

How to know if address is SegWit?

Native SegWit (Bech32): starts with "bc1" P2SH-wrapped SegWit: starts with "3" (same as normal P2SH, need to verify) Legacy: starts with "1"

Does SegWit solve scalability problems?

Partially. Increases capacity ~2-3x. But doesn't solve all problems. Lightning Network and other solutions complement.

Why doesn't everyone use SegWit?

Adoption takes time. Wallets need to update. Users need to migrate. Legacy compatibility allows slow transition. Natural process.

Conclusion

SegWit was fundamental upgrade that fixed transaction malleability, increased network capacity, and prepared ground for future upgrades like Lightning Network and Taproot. Understanding SegWit is understanding how Bitcoin evolves in compatible and safe way.

The main points you need to understand are:

SegWit separates witness from body - Signatures stay separated, don't count in base limit
Fixes malleability - TXID is immutable, foundation for Lightning Network
Increases capacity - ~2-3x more transactions through weight units
Compatible soft fork - Doesn't break old transactions, gradual adoption
Preparation for future - Foundation for Taproot and other upgrades
Significant impact - Lower fees, more capacity, better experience

SegWit demonstrated how Bitcoin can evolve through careful soft forks. Without breaking compatibility, SegWit brought significant improvements benefiting entire network. It's example of how upgrades can be implemented safely and gradually.

Malleability fix was particularly important. It allowed Lightning Network to work correctly, opening door for instant and low-cost payments. Without SegWit, Lightning wouldn't be possible safely.

Capacity increase was also significant. Even if not complete scalability solution, it increased network capacity ~2-3x, reducing congestion and fees. Prepared ground for future growth.

If you want to understand how Bitcoin evolves, how upgrades are implemented, or how technical problems are solved, understanding SegWit is essential. It's fundamental upgrade that demonstrated how Bitcoin can improve while maintaining compatibility and security.