BIP141 - Segregated Witness (Consensus Layer)¶

BIP141 (Bitcoin Improvement Proposal 141) is one of the Bitcoin improvement proposals, put forward by Eric Lombrozo, Johnson Lau, and Pieter Wuille in 2015. It defines the consensus layer rules for Segregated Witness (SegWit). This is one of the most important upgrades in the history of the Bitcoin protocol, fundamentally changing the transaction structure and block verification mechanism.

Core Concept¶

The core idea of Segregated Witness is to separate the transaction signature data (witness data) from the transaction body. In traditional Bitcoin transactions, signature data and transaction data are mixed together. SegWit moves signature data to an independent data structure, solving the transaction malleability problem while increasing block capacity.

SegWit introduced a new script versioning system that uses witness programs to define output conditions. This provides a clear upgrade path for future protocol upgrades (such as Taproot).

Key Features¶

1. Transaction Malleability Fix¶

Transaction malleability refers to the issue where a transaction ID can be modified before the transaction is confirmed:

Old Problem: - Signature data is part of the transaction ID - Third parties can modify the signature without affecting validity - This causes the transaction ID to change, breaking dependency chains - Layer 2 protocols like the Lightning Network could not operate safely

SegWit Solution: - Signature data is no longer included in the transaction ID calculation - The transaction ID is based solely on non-witness data - Completely eliminates third-party malleability attacks - Makes the Lightning Network possible

2. Block Capacity Increase¶

SegWit increases capacity by introducing the block weight concept:

Block weight = base data x 4 + witness data x 1
Maximum weight = 4,000,000 weight units

Practical Effect: - Old block limit: 1 MB - SegWit block: up to ~4 MB (theoretical) - Typical SegWit block: 1.8-2.2 MB - Capacity increase of approximately 100-120%

3. Script Versioning¶

Introduces a witness version system for easier future upgrades:

Witness program format:
OP_0 <32-byte hash>     -> Version 0 (current SegWit)
OP_1 <32-byte data>     -> Version 1 (Taproot, BIP341)
OP_2-OP_16              -> Reserved for future versions

4. New Address Format¶

SegWit introduced the Bech32 address format:

Legacy address (P2PKH):  1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Legacy multisig (P2SH):  3J98t1WpEZ73CNmYviecrnyiWrnqRhWNLy
SegWit v0 (P2WPKH):      bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
SegWit v0 (P2WSH):       bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3

Bech32 Advantages: - Entirely lowercase, avoiding confusion - Includes error detection codes - More efficient QR code encoding - Lower transaction fees

5. Signature Hash Optimization¶

BIP141, combined with BIP143, improved the signature hash algorithm: - Prevents the quadratic hashing problem (O(n^2) complexity attack) - Reduces the computational cost of signature verification - Improves processing efficiency for large transactions

Technical Details¶

Witness Data Structure¶

SegWit transactions contain two parts:

1. Base Transaction Data (used to calculate txid):

Version
Input count
Input list (without signatures)
Output count
Output list
Locktime

2. Witness Data (not included in txid):

Witness count
Witness stack for each input
  - Number of stack items
  - Length and data of each stack item

P2WPKH (Pay to Witness Public Key Hash)¶

Native SegWit single-signature output:

Output script: OP_0 <20-byte public key hash>

Witness data:
  <signature>
  <public key>

Equivalent to traditional P2PKH, but the signature is in the witness section.

P2WSH (Pay to Witness Script Hash)¶

Native SegWit script output:

Output script: OP_0 <32-byte script hash>

Witness data:
  <signature1>
  <signature2>
  ...
  <actual script>

Equivalent to traditional P2SH, but all witness data is separated.

P2SH-P2WPKH (Nested SegWit)¶

Introduced for compatibility with older wallets:

P2SH script: OP_HASH160 <20-byte hash> OP_EQUAL

Redeem script: OP_0 <20-byte public key hash>

Witness data:
  <signature>
  <public key>

The address starts with 3, appearing the same as a regular P2SH address.

Block Weight Calculation¶

Weight = (base size x 3 + total size) bytes

Where:
- Base size = transaction size without witness data
- Total size = complete transaction size including witness data
- Maximum weight = 4,000,000 units

Conversion:
- Pure legacy transaction: 1 byte = 4 weight units
- Pure SegWit transaction: ~1 byte = 1-1.5 weight units (depending on witness data ratio)

Witness Commitment¶

Miners include a witness commitment in the coinbase transaction:

Coinbase output script:
  OP_RETURN <0xaa21a9ed><32-byte witness root hash>

Witness root calculation:
  Witness Root = Merkle Root(wtxid of all transactions)
  wtxid = complete transaction hash including witness data

This ensures the integrity and immutability of witness data.

Technical Advantages¶

Malleability Fix¶

• Lightning Network feasible: No malleability, so unconfirmed transaction chains can be safely constructed
• Complex smart contracts: Multi-layer transaction dependencies become possible
• Stable transaction IDs: Easier tracking and auditing

Capacity Increase¶

• More transactions: Same block space accommodates more transactions
• Lower fees: Increased supply reduces bidding pressure
• Network scaling: Provides room for Bitcoin's future growth

Performance Optimization¶

• Faster signature verification: BIP143 eliminates the quadratic hashing problem
• Hardware wallet friendly: Simplifies signature computation
• Faster node verification: Optimized hashing algorithm

Upgrade Path¶

• Script versioning: Reserves space for future upgrades like Taproot
• Backward compatible: Old nodes can still validate blocks
• Flexible extension: 16 witness versions available

Relationship with Other BIPs¶

BIP143 (Transaction Signature Verification)¶

Defines the signature hash algorithm for SegWit transactions: - Fixes the quadratic hashing problem - Commits to input amounts during signing - Improves hardware wallet security

BIP144 (Peer-to-Peer Services)¶

Defines the network transmission format for SegWit: - New message types and service bits - Serialization of witness data - Data synchronization between nodes

BIP173 (Bech32 Addresses)¶

Defines the native SegWit address format: - Human-readable prefix (bc for mainnet) - Error detection codes - Lowercase characters only

BIP341 (Taproot)¶

Based on SegWit v1: - Uses OP_1 witness version - Introduces Schnorr signatures (BIP340) - Further improves privacy and efficiency

BIP9 (Version Bits Activation)¶

SegWit uses the BIP9 activation mechanism: - Signals via version bit 1 - Miners vote to reach consensus - Avoids a hard fork

Activation and Deployment¶

Soft Fork Activation¶

SegWit was activated in August 2017: - Activation method: BIP9 version bit 1 - Activation height: 481,824 (August 24, 2017) - Lock-in period: 2,016 blocks (~2 weeks) - Miner support: Required 95% signaling support

Activation Timeline¶

1. December 2015: BIP141 proposal published
2. November 2016: Signaling period officially began
3. May 2017: Progress was slow, sparking controversy
4. July 2017: Activation accelerated via BIP91
5. August 9, 2017: Reached 95% threshold, locked in
6. August 24, 2017: Officially activated

Compatibility¶

Backward Compatible: - Old nodes treat SegWit transactions as "anyone-can-spend" - Old nodes can validate blocks but do not verify witness data - No chain split occurs

Forward Compatible: - New nodes fully verify witness data - Invalid witness transactions are rejected - Consensus rules remain consistent

Adoption Status¶

Wallet Support¶

Hardware Wallets: - Ledger, Trezor, Coldcard fully support SegWit - Both native SegWit and nested SegWit are supported

Software Wallets: - Bitcoin Core, Electrum, Wasabi - BlueWallet, Muun, Phoenix

Exchange Support¶

• Coinbase, Kraken, Gemini, and other major exchanges
• Significantly reduced withdrawal fees
• Improved transaction processing efficiency

Network Statistics¶

As of 2024: - SegWit transaction share: 70-85% - Native SegWit share: 60-70% - Average block size: 1.5-2.0 MB - Fee savings: 30-60% (compared to legacy transactions)

Practical Impact¶

Impact on Users¶

• Lower fees: SegWit transactions are cheaper
• Faster confirmations: Increased capacity reduces congestion
• New address format: Requires adapting to Bech32 addresses
• Better privacy: Paves the way for privacy technologies like Taproot

Impact on Developers¶

• Lightning Network: Became possible and developed rapidly
• Smart contracts: More complex contracts became viable
• New tools: Needed to support new transaction formats
• Optimization opportunities: Batch payments, CPFP, and other techniques

Impact on Miners¶

• Block rewards: More transactions = more transaction fees
• Verification cost: Slightly increased (witness data verification)
• Competitive pressure: Software upgrades required to support SegWit

Security Considerations¶

1. Address Verification¶

When using SegWit addresses: - Verify that the receiving address format is correct - Distinguish between native SegWit and nested formats - Test with small amounts before sending large amounts

2. Software Upgrades¶

• Ensure wallet and node software supports SegWit
• Non-upgraded software may not fully verify transactions
• Hardware wallets require firmware updates

3. Change Addresses¶

When mixing legacy addresses and SegWit addresses: - Address ownership information may be leaked - Using SegWit addresses consistently is recommended - Improves privacy protection

4. Fee Estimation¶

SegWit changes fee calculations: - Uses virtual bytes (vBytes) instead of bytes - Different transaction types have different fee rates - Accurate estimation is needed to avoid overpaying or underpaying fees

Comparison: Before and After SegWit¶

Controversy and Criticism¶

Activation Controversy¶

The SegWit activation process triggered a major split in the Bitcoin community: - Supporters: Considered it a necessary technical upgrade - Opponents: Preferred directly increasing block size (hard fork) - Result: Led to the Bitcoin Cash (BCH) fork

Technical Criticism¶

• Increased complexity: Transaction structure became more complex
• Verification cost: Witness data requires additional verification
• Adoption speed: Early adoption rate was lower than expected
• Discount controversy: The witness data "discount" raised fairness concerns

Positive Outcomes¶

Despite the controversy, SegWit has proven successful: - Malleability issue completely resolved - Capacity significantly increased - Paved the way for upgrades like Taproot - Lightning Network flourished

Future Development¶

Layer 2 Expansion¶

SegWit provides the foundation for Layer 2 protocols: - Lightning Network: Micropayment channels - State channels: Smart contract channels - Sidechains: Two-way pegging

Further Optimization¶

Future improvements based on SegWit: - Cross-input signature aggregation: Further reduces transaction size - New witness versions: Introduces more advanced features - Batch verification: Accelerates block verification

Taproot and Beyond¶

SegWit v1 (Taproot) has been activated: - Schnorr signatures - MAST (Merklized Abstract Syntax Tree) - Stronger privacy and efficiency

Summary¶

BIP141, through the introduction of Segregated Witness, brought multiple significant improvements to Bitcoin:

Core Achievements: - Fixed malleability: Eliminated a long-standing technical flaw - Increased capacity: Block capacity increased by approximately 100% - Optimized performance: More efficient signature verification - Extensibility: Provided a clear path for future upgrades

Practical Value: - Reduced transaction fees by 30-60% - Made the Lightning Network possible - Supports more complex smart contracts - Laid the foundation for advanced technologies like Taproot

Historical Significance: - One of the most important technical upgrades in Bitcoin history - Demonstrated the Bitcoin community's ability to coordinate complex upgrades - Proved the effectiveness of soft forks as an upgrade mechanism - Despite a winding path, ultimately achieved widespread adoption

BIP141 not only solved immediate technical problems but also opened up new possibilities for Bitcoin's long-term development. The successful activation and widespread adoption of SegWit demonstrates the adaptability and innovative capacity of the Bitcoin network, preparing it for future challenges.