Nested vs. Native SegWit (P2SH vs. Bech32)

When SegWit was first released, the Bitcoin ecosystem faced a challenge: many older wallets didn't recognize the new address format. To solve this, two different ways of using SegWit were created: Nested and Native.

1. Nested SegWit (P2SH)

• Address Prefix: Starts with a 3 (e.g., 3J98t...).

• How it works: It "wraps" a SegWit script inside a standard P2SH (Pay-to-Script-Hash) address.

• Compatibility: Excellent. Even the oldest wallets can send money to a 3... address.

• Downside: Because of the "wrapping," it is slightly larger and more expensive than Native SegWit. It was designed as a temporary bridge.

2. Native SegWit (Bech32)

• Address Prefix: Starts with bc1q (e.g., bc1q9...).

• Standard: BIP173.

• How it works: It uses the new address format specifically designed for SegWit.

• Compatibility: Initially low (2017), but now widely supported by all major wallets and exchanges.

• Benefit: It is the most efficient and cheapest way to send Bitcoin. It is also case-insensitive and has better error detection.

3. The "Anyone-Can-Spend" Mechanism

Both formats use a special type of script that old nodes see as "Anyone-Can-Spend."

• Legacy Node: Sees the transaction and thinks "Cool, anyone can take this money without a signature."

• SegWit Node: Sees the transaction and thinks "Wait, this is a SegWit script. I need to go look in the Witness data for the signature before I accept this." This is why SegWit was a Soft Fork and didn't split the network.

4. Witness Versioning

SegWit introduced a "Version Byte" (starting at 0).

• Version 0: Standard SegWit (P2WPKH).

• Version 1: Taproot (P2TR), which was activated later. This allows Bitcoin to add future upgrades without needing another major structural change like SegWit.

Type	Address	Encoding	Fee Savings
Legacy	1...	Base58	0%
Nested	3...	Base58	~20%
Native	bc1q...	Bech32	~40%

In the final section, we will build a Python SegWit Auditor.