Private key → P2SH-P2WPKH address (nested SegWit)

What this page computes

This is the nested SegWit address: SegWit locking logic hidden inside a P2SH wrapper so that it produces an ordinary-looking 3… address. There are six layers, and this page prints every one of them:

Because the inner value is hashed twice — once as the public key, once as the redeem script — this address type lives in a slightly awkward middle ground between legacy P2PKH and native SegWit. The comparison table near the end quantifies exactly how much that costs.

1. P2SH: pay to script hash

P2SH was added by BIP16 and activated on 1 April 2012. Before it, a sender had to reproduce the recipient's full spending conditions in the output: a multi-signature address, for example, meant putting the whole 2 <key> <key> <key> 3 OP_CHECKMULTISIG program — hundreds of bytes — into the transaction, and paying for them.

P2SH inverts that. The output commits only to the hash of a script, and the script itself is revealed only when the coins are spent:

P2SH scriptPubKey:   OP_HASH160  <20-byte script hash>  OP_EQUAL
the spender later supplies:  <...the full redeem script...>

The rules that make this safe are the interesting part:

• The spender's unlocking script must contain the redeem script whose hash matches, plus whatever that script requires to be satisfied.
• The interpreter hashes the supplied script, compares it with OP_EQUAL, and only then executes the script as a program of its own.
• The redeem script is not part of the address. An address is only a hash, so it cannot tell you what the spending conditions are — a subtlety that matters for the whole SegWit design.

2. What SegWit changed

SegWit ("segregated witness", BIP141, activated 24 August 2017) moved the signature data — the witness — out of the structure that the transaction ID is computed over, and gave it a cheaper accounting unit:

The size accounting is the part you can feel in your fees. Weight is measured in weight units (WU) and the effective size in virtual bytes (vB):

So every witness byte costs a quarter of what a base-layer byte costs, which is why SegWit inputs are cheaper to spend. A native P2WPKH output is simply OP_0 <20-byte hash160> — 22 bytes, no OP_DUP, no OP_CHECKSIG, nothing to execute beyond "the witness must satisfy this program".

3. Why nested SegWit exists at all

SegWit's native address format is bech32: bc1q…. In 2017 that was a new string format that older wallets, exchanges and payment processors simply did not understand — many would reject it as invalid, and some would refuse to send to it at all.

Nested SegWit (3…) solved the deployment problem, not a cryptographic one:

• A 3… address is indistinguishable from an ordinary P2SH address. Any wallet that could already pay a multisig 3… address needed no upgrade to pay a SegWit one — the sender does not have to understand witness at all.
• The recipient gets the SegWit benefits: signature malleability is gone and the spend is discounted by the weight rule. (The recipient pays the fee on the way out, so they keep the saving.)
• The trade-off is real: the wrapper adds a 22-byte redeem script to the scriptSig and an extra hash, so nested SegWit is more expensive than native bc1q…. BIP49 standardised the derivation path m/49'/0'/0'/0/i so that wallets could restore these addresses deterministically.

4. The redeem script, byte by byte

The redeem script is the smallest valid witness program there can be for a single key — 22 bytes, and every one of them is accounted for:

Two details are worth noticing. First, the version byte is OP_0, not a separate "version" field — the witness version is encoded as a small script number, which is why v1 (Taproot) starts with OP_1 (0x51) and uses bech32m instead of bech32. Second, this 22-byte string is identical to a native P2WPKH scriptPubKey: the same program is used two different ways, once directly in the output and once wrapped inside a P2SH hash.

redeem script (22 bytes)          = 00 14 21f57b6d…9012
P2SH scriptPubKey (23 bytes)      = a9 14 823333d5…8b6e 87
                                    │  │  └─ 20-byte hash160(redeem script)
                                    │  └──── push 20 bytes
                                    └─────── OP_HASH160 … OP_EQUAL (87)

5. The double hashing, and what it costs

For a native P2WPKH address the chain is: hash the key once, bech32-encode the 20 bytes. For a nested address the chain is: hash the key, build the 22-byte script, hash that, then Base58Check-encode the second hash. Two hash operations over two different inputs produce two unrelated 20-byte values — and the second one is what the address carries.

At spend time the scriptSig must carry that 22-byte script (1 push opcode + 22 bytes = 23 bytes) so the network can hash it and see the witness program. Those 23 bytes sit in the base part of the transaction and cost 4 weight units each, which is the whole reason nested SegWit is not as cheap as native:

Nested SegWit therefore saves about 57 vB (38%) against legacy P2PKH but still pays 23 vB (25%) more than native bech32. The output side is smaller in both SegWit cases, because the scriptPubKey is shorter: 32 bytes for a P2SH output, 31 for P2WPKH, 34 for P2PKH.

6. Comparison table

7. Worked example with the demo key

Notice that the native and nested siblings share the same 20-byte witness program 21f57b6d…9012, yet produce completely different addresses — and, from the outside, an unrelated-looking scriptPubKey. Only the nested one is wrapped in a second hash.

8. What this address is not

• Not a multi-signature address. 3… is the P2SH prefix, and multisig wallets use it too. Nothing in the string tells you whether the hidden script is a single-key witness program or a 2-of-3 multisig.
• Not automatically cheaper than bc1q…. It saves against legacy P2PKH only. If the recipient's wallet supports bech32, native is cheaper and simpler for everybody.
• Not a way to hide anything. When the coins are spent, the redeem script is published in the scriptSig and the witness program in the witness. The address only delays transparency until the first spend; the blockchain is public forever.
• Not interchangeable with its siblings when restoring. A wallet that only derives 1… and bc1q… addresses will not see coins sitting at 3…, even with the right seed. Worse, there is no way to guess from the address alone which of the P2SH flavours it is — the wallet must be told to derive nested SegWit.

9. Where this fits in the chain

• Same key, other wrappers: P2PKH compressed, P2PKH uncompressed, native P2WPKH, Taproot P2TR.
• Inspect the wrapper without a private key: Base58Check decoder shows the 0x05 version byte and the 20-byte script hash.
• Decode the inner program: the bech32 page shows the same 20 bytes as witness v0 in bc1q… form.

10. Security notes

• P2SH hides the spending conditions, not the amounts or the addresses. Privacy comes from using fresh addresses per payment, not from the wrapper.
• The 4-byte Base58Check checksum on a 3… address catches typos with probability 1 − 2^-32; it is not a signature and cannot protect against a substituted address.
• Verify that the wallet you intend to restore from a seed actually derives nested SegWit addresses before you conclude that funds are missing.

11. Common mistakes

• Assuming 3… means multisig. Since 2017 most 3… addresses in the wild are single-key nested SegWit.
• Expecting nested SegWit fees to match bech32. The extra 22-byte redeem script and the second hash make it strictly more expensive than native SegWit.
• Using an uncompressed key's hash as the witness program. Valid-looking address, unspendable in practice.
• Restoring a seed into a wallet with the wrong script-type list. BIP49 (m/49'/0'/0'/0/i) exists precisely so nested addresses are reproducible; a BIP44-only wallet will show zero.
• Assuming the redeem script is in the address. It is not — the address is a hash, and the script only appears when the coins move.

12. Quick reference