MASTERING-BITCOIN · Unit 7 · Video 3

The 20-Byte Trick: P2SH — Interactive Practice

IKey Reference

Concept	Formula / Value	Description
P2SH redeem hash	$\text{HASH160}(s) = \text{RIPEMD160}(\text{SHA256}(s))$	20-byte commitment to a script
P2SH output script	`OP_HASH160 <20-byte hash> OP_EQUAL`	23 bytes total, regardless of script complexity
Address encoding	`Base58Check(0x05 \| hash160)`	BIP13 — version byte 0x05 → addresses starting with `3`
Validation	Stage 1: hash matches → Stage 2: execute redeem script	Two-stage spend verification

IIVisualization 1: How Big Is The Output? (P2SH vs No P2SH)

Before P2SH, every customer paying Mohammed had to embed his entire multisig script in their transaction output. With P2SH, they just commit to a 20-byte hash — no matter how complex the underlying contract.

Use the sliders below to vary the multisig configuration and see how the output script size changes.

⚙ interactive visualization — coming to this page format soon

Notice: The P2SH output is always 23 bytes — whether the underlying script is a simple 1-of-2 multisig or a giant 15-of-15. The complexity has been compressed into a single 20-byte fingerprint. What does this say about who bears the cost of complex scripts?

IIIVisualization 2: The Burden Shift — Who Pays The Bytes?

P2SH does not delete the redeem script's bytes; it moves them. Use the slider below to choose a moment in the lifecycle of a payment, and see who bears the cost.

⚙ interactive visualization — coming to this page format soon

Reflect: Step through all three stages. With P2SH, the customer sends a tiny output, and every full node stores only 23 bytes in the UTXO set. The full redeem script appears on-chain only at spend time, and the cost is borne by the spender — the person who actually knows and benefits from the script.

IVVisualization 3: From Script To Address (BIP13 Pipeline)

A P2SH address is just a 20-byte hash, dressed up with a version byte and a checksum. Use the dropdown to inspect each step of the pipeline.

⚙ interactive visualization — coming to this page format soon

Notice: Step 3 is the heart of the trick — every Bitcoin script in the world, no matter how complex, gets compressed to exactly 20 bytes. The version byte 0x05 in step 4 is what produces an address starting with the digit 3 (compare to P2PKH version 0x00 → addresses starting with 1).

VQuiz Questions

Question 1

A P2SH address always starts with which character, and why?

✅ Correct! Version byte 0x05 → leading character 3.

❌ Not quite. P2SH was defined before SegWit, and uses Base58Check (not Bech32) with version byte 0x05.

Show solution

Solution:

BIP13 specifies that the 20-byte HASH160 of the redeem script is prepended with the version byte 0x05, then encoded with Base58Check. The version byte 0x05 deterministically maps to addresses whose first Base58 character is 3.

For comparison:

Version byte 0x00 → P2PKH addresses starting with 1
Version byte 0x05 → P2SH addresses starting with 3
(Bech32 / SegWit native addresses use a different encoding entirely and start with bc1)

Question 2

True or False: P2SH makes the redeem script secret — the network never learns what the underlying contract is.

✅ Correct! P2SH defers the reveal; it doesn't hide forever.

❌ Not quite. This is a common misconception — the script appears fully on-chain when the coins are spent.

Show solution

Solution:

P2SH defers the script; it does not hide it permanently. At funding time, only the 20-byte HASH160 commitment appears on-chain. But when the recipient spends those coins, the spending transaction's input contains the full redeem script in plain view, where:

Stage 1 of validation hashes the presented redeem script and checks it matches the committed hash.
Stage 2 executes the redeem script with the provided signatures.

So the privacy benefit is temporal (nobody sees the script until the money moves), not secrecy (the script is fully public at spend time).

Question 3

A customer pays Mohammed using a P2SH address. The output script in that funding transaction is exactly:

OP_HASH160 <20-byte hash> OP_EQUAL

Including the opcodes and the push-20 length byte, how many bytes is this output script?

✅ Correct! 1 + 1 + 20 + 1 = 23 bytes, regardless of script complexity.

❌ Close, but — you forgot the two opcodes (OP_HASH160, OP_EQUAL) and the push-length byte.

❌ Not quite. The whole point of P2SH is that the output size is fixed and small — the redeem script's bytes don't appear here.

Show solution

Solution:

A P2SH output script is always exactly 23 bytes:

Component	Bytes
`OP_HASH160`	1
Push-20 length byte (0x14)	1
The 20-byte hash	20
`OP_EQUAL`	1
Total	23

This is the magic of P2SH: regardless of whether the redeem script is a 1-of-2 multisig, a 15-of-15, or some elaborate timelock, the on-chain output is always the same 23 bytes. The 200-byte redeem script only appears later, in the input of the spending transaction.

Question 4

Alice constructs a P2SH address from a redeem script that contains a typo and is not a valid Bitcoin script. Bob doesn't know this and sends 1 BTC to the address. What happens?

✅ Correct! The network can't validate a script it hasn't seen yet — and once it sees it at spend time, it's too late.

❌ Not quite. Remember: at funding time, the network only sees the 20-byte hash. It cannot inspect the redeem script until someone tries to spend.

Show solution

Solution:

This is the sharp edge of P2SH. At funding time, the network sees only OP_HASH160 <hash> OP_EQUAL — it has no way to know what redeem script that hash commits to, much less whether it is valid. So Bob's payment confirms normally.

The problem appears at spend time:

Stage 1 (hash check): The presented redeem script hashes to the committed value. ❌ Wait — actually this passes, because the hash was computed over the broken script.
Stage 2 (execute redeem script): The script is malformed and fails to execute. The spend is rejected.

There's no other way to spend the output, so the coins are permanently locked. The network had no opportunity to warn anyone, because a P2SH address gives zero guarantee about the validity of the underlying script.

This same hazard explains why nesting P2SH inside P2SH is forbidden, and why putting OP_RETURN in a redeem script silently destroys funds.

Solved: 0 / 4