Nested SegWit: Fee Savings and the Discount

The main reason users switched to Nested SegWit was the Economic Incentive. By using the Witness field, users could pack more transactions into a single block and pay fewer "Sats per Byte" on average.

1. The Weight Calculation

SegWit introduced the concept of Weight Units (WU).

• Base Data: 4 WU per byte (Expensive).

• Witness Data: 1 WU per byte (Cheap). In Nested SegWit, the ScriptSig (the 22-byte script) is still Base Data, but the signature and public key are moved to the Witness.

2. Comparing P2PKH vs. Nested SegWit

In a standard P2PKH spend, the signature and public key are in the ScriptSig, costing 4 WU per byte. In a Nested SegWit spend, those same bytes cost only 1 WU per byte.

Transaction Component	P2PKH Cost	Nested SegWit Cost
Transaction Header	4 WU/byte	4 WU/byte
Outputs	4 WU/byte	4 WU/byte
Signatures	4 WU/byte	1 WU/byte
Public Keys	4 WU/byte	1 WU/byte

3. Real-World Impact

On average, a Nested SegWit transaction is about 25% cheaper than a Legacy transaction. For a user making hundreds of transactions, this adds up to significant savings. It also allowed the network to process more transactions per block, effectively increasing the "Block Size" without actually changing the 1MB limit for legacy nodes.

4. The "Nested" Tax

Nested SegWit is slightly more expensive than Native SegWit (Bech32).

• This is because Nested SegWit still requires the 22-byte Redeem Script in the ScriptSig (Base Data).

• Native SegWit removes the ScriptSig entirely, saving even more space.

Type	Virtual Size (vByte)	Avg. Fee Savings
Legacy	148 vB	0%
Nested	110 vB	~25%
Native	104 vB	~30%

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