Nested SegWit (P2SH-P2WPKH): The Anchor Guide to the SegWit Bridge

🔍 Why This Module Matters

When SegWit launched, the Bitcoin ecosystem was fragmented. Some exchanges supported it, others didn't. To prevent the network from splitting, developers needed a way to make SegWit look like "Old" Bitcoin. Nested SegWit was the solution. It is the "Trojan Horse" of Bitcoin upgrades—hiding modern, efficient logic inside a legacy container. This module will deconstruct the "Wrapper" mechanism, explain why "3" addresses are so common, and detail the fee-efficiency trade-offs of this hybrid format.

🏛️ The Hybrid Architecture: A SegWit Trojan Horse

Nested SegWit works by using two layers of locking.

1. The Outer Layer (P2SH): The transaction looks like a standard "Pay to Script Hash" to old nodes. They see an address starting with 3 and think: "I'll just wait for the user to provide a script that matches this hash."

2. The Inner Layer (P2WPKH): Inside that P2SH "box" is a modern SegWit witness program. When a modern node sees the script, it realizes: "Aha! This isn't just a normal script; it's a SegWit script in disguise."

graph LR
 A[Legacy Wallet Sender] -->|Sends to| B[P2SH Address: 3...]
 B -->|Contains| C[Nested SegWit Program]
 C -->|Uses| D[Witness Data Area]
 D -->|Saves| E[Transaction Fees]

⚙️ Why Use Nested SegWit Today?

While Native SegWit (bc1q) is more efficient, Nested SegWit remains relevant for one primary reason: Compatibility.

• Maximum Reach: Every wallet and exchange on Earth supports "3" addresses. If you are receiving a payment from an old or unknown source, a Nested SegWit address is the safest way to ensure the payment goes through while still getting some fee benefits.

• The Price of Compatibility: Because Nested SegWit requires a "Redeem Script" to be stored in the transaction input, it is slightly more expensive (uses more bytes) than Native SegWit, but still significantly cheaper than Legacy "1" addresses.

🛠️ Fee Comparison: The Weight of the Wrapper

Note: Estimates based on a standard 1-input, 2-output transaction.

🛡️ The Redeem Script: The Secret Bridge

For a Nested SegWit spend to work, the user must provide a 22-byte Redeem Script that looks like this: 00 14 <20-byte-Key-Hash>

• 00: Version 0 SegWit.

• 14: Length of the following hash (20 bytes).

• Hash: The fingerprint of the owner's public key.

• The Trick: Old nodes see this as a valid data push; new nodes see it as a "Witness Program."

🎯 Learning Objectives for this Module

By the end of this module, you will be able to:

1. Define Nested SegWit and identify its address prefix (3).

2. Explain the historical necessity of the "Bridge" between legacy and native formats.

3. Contrast the fee efficiency of Nested vs. Native SegWit.

4. Describe how the "Redeem Script" hides modern logic from old nodes.

5. Understand why a "3" address can represent either a multisig or a single-key SegWit account.

🗺️ Module Roadmap: What's Next?

Now that we've bridged the gap, we will look at the technical guts:

1. Nested SegWit Redeem Script: A byte-by-byte deconstruction of the wrapper.

2. Compatibility Mapping: Which services still require "3" addresses today.

3. Fee Calculation (Nested): Calculating the exact byte-savings of P2SH-P2WPKH.

4. Python Nested SegWit Auditor: Writing a script to derive a "3" address from a SegWit program.

🎓 Summary

Nested SegWit is a testament to Bitcoin's commitment to backward compatibility. It allowed the network to upgrade its entire economic foundation without leaving anyone behind. By mastering the "Wrapped" logic of Nested SegWit, you are understanding the sophisticated engineering that keeps Bitcoin unified and functional across multiple generations of software.