MASTERING-BITCOIN · Interactive Practice | Unit 4 · Video 4

The 20-Byte Gamble: P2SH and the Hidden Expiration Date

IKey Formulas

Concept	Formula / Value	Description
HASH160	$\text{HASH160}(x) = \text{RIPEMD160}(\text{SHA256}(x))$	Produces a 20-byte (160-bit) digest used in P2SH
P2SH output template	$\texttt{OP\_HASH160}\ \langle\text{20-byte hash}\rangle\ \texttt{OP\_EQUAL}$	The exact script pattern nodes recognize as P2SH
Preimage / 2nd-preimage work	$2^{n}$	Work to invert or match a fixed $n$ -bit hash
Birthday bound (collision)	$2^{n/2}$	Work to find any two inputs colliding on an $n$ -bit hash
HASH160 collision security	$2^{160/2} = 2^{80}$	Matches Bitcoin's hourly hashrate
SHA-256 collision security	$2^{256/2} = 2^{128}$	~ $3.2 \times 10^{10}$ years at today's hashrate

IIVisualization 1: How Hash Size Sets the Security Margin

The security of a hash commitment depends on the type of attack and the bit length $n$ . Preimage and second-preimage attacks take $2^n$ work. Collision attacks — where the attacker controls the input — take only $2^{n/2}$ work thanks to the birthday bound.

Move the slider to change the hash output size and see how the three attack costs compare. Then see how long each would take on hardware running at $2^{80}$ hashes per hour (roughly today's Bitcoin mining network).

⚙ interactive visualization — coming to this page format soon

Notice: At $n = 160$ (HASH160, the P2SH standard), collision work is only $2^{80}$ — roughly one hour of global Bitcoin mining. At $n = 256$ (SegWit's P2WSH / Taproot), collision work is $2^{128}$ — well beyond the age of the universe. Doubling the hash length doesn't double security; it squares the collision-breaking time.

IIIVisualization 2: The Birthday Attack on P2SH

Why is collision the scary attack? Because the attacker can shape the input. In the P2SH collision attack, a malicious multisig participant grinds two scripts in parallel:

An honest redeem script (legitimate keys)
An evil redeem script (pays only to the attacker)

They tweak a nonce in each, hash both, and collect digests into two piles of size $k$ . By the birthday bound, once $k \approx 2^{n/2}$ they are very likely to find a match. Then they publish the honest script, let victims fund the address, and later reveal the evil script — which hashes to the same 20 bytes.

Adjust the hash size and the attacker's grinding budget to see the collision probability.

⚙ interactive visualization — coming to this page format soon

Reflect: The curve jumps from "impossible" to "near certain" right around $k = 2^{n/2}$ . This is why we say the birthday bound is the real security level against a collision attack. For real HASH160 we can't simulate $n = 160$ directly, but the shape of the probability curve is identical — just shifted to $k \approx 2^{80}$ .

IVVisualization 3: Network Hashrate vs. Time to Break

How does the collision threat scale as Bitcoin's mining hashrate grows (or shrinks)? The network's aggregate work per hour is currently around $2^{80}$ HASH160-equivalent operations. If dedicated hashing hardware eventually reaches that same scale, $2^{80}$ HASH160 collisions become practically grindable.

Pick an attacker hashrate and compare how long it takes to collide a 160-bit hash vs a 256-bit hash.

⚙ interactive visualization — coming to this page format soon

Notice: At roughly $2^{80}$ hashes per second (far beyond today's total Bitcoin network, which does $2^{80}$ per hour), a 160-bit hash collides in seconds, while a 256-bit hash still needs more time than the age of the universe. This is the structural reason Bitcoin migrated to 32-byte script hashes in SegWit (P2WSH) and Taproot (P2TR).

VQuiz Questions

Question 1 · Collision Work for HASH160

P2SH commits to a 20-byte (160-bit) HASH160 digest of the redeem script. Assuming the hash function behaves ideally, how much work is required to find any pair of inputs that collide on the same 20-byte output?

✅ Correct! The birthday bound gives $2^{n/2} = 2^{80}$ for a 160-bit hash.

❌ Not quite. $2^{160}$ is the cost of a preimage or second-preimage attack, not a collision. Collisions benefit from the birthday bound.

❌ Not quite. Apply the birthday bound: $2^{n/2}$ with $n = 160$ .

Show solution

Solution:

By the birthday bound, finding any collision on an $n$ -bit hash takes roughly $2^{n/2}$ work, not $2^n$ .

For HASH160 with $n = 160$ : $\text{collision work} \approx 2^{160/2} = 2^{80}$

$2^{160}$ is the work for a preimage or second-preimage attack (where the target hash is fixed).
$2^{80}$ is the work for a collision attack (where the attacker picks both inputs).

This matches the entire Bitcoin mining network's output per hour, which is exactly why the margin is considered dangerously thin.

Question 2 · Why Collision, Not Preimage?

A group sets up a P2SH multisig address. Mallory is the last participant to contribute a public key. Before submitting, she secretly grinds two script variants in parallel: an honest one using everyone's keys, and an evil one that pays only her. She hashes both until their 20-byte digests match, then publishes the honest version.

Why does this attack cost only $2^{80}$ work instead of $2^{160}$ ?

✅ Correct! Collision attacks are cheap precisely because the attacker shapes both inputs.

❌ Not quite. The $2^{80}$ figure comes from the birthday bound, which only applies when the attacker controls both inputs to the hash.

Show solution

Solution:

The difference between preimage and collision work comes down to who controls the input.

In a second-preimage attack, the honest script is fixed first and the attacker must find a different input hashing to the same value. Cost: $2^{160}$ .
In a collision attack, the attacker freely varies both scripts in parallel, collecting two piles of hashes and waiting for any match. By the birthday bound, this costs only $2^{n/2} = 2^{80}$ .

The weakness isn't that HASH160 is broken — it's that the P2SH protocol lets the attacker shape the committed input before publishing. The 20-byte hash size and the mining hashrate are both relevant facts, but the structural reason the attack is cheap is that Mallory picks both inputs.

Question 3 · Why SegWit and Taproot Switched to 32-Byte Hashes

SegWit's P2WSH and Taproot's P2TR use a 32-byte SHA-256 script hash instead of a 20-byte HASH160. Roughly how much work does a collision attack now require, and by what factor has the collision cost increased relative to P2SH?

✅ Correct! Jumping from 160 to 256 bits multiplies collision cost by $2^{48}$ .

❌ Not quite. Apply the birthday bound to each: $2^{160/2}$ vs $2^{256/2}$ , then divide.

Show solution

Solution:

The collision security of an $n$ -bit hash is $2^{n/2}$ .

P2SH (HASH160, $n = 160$ ): collision cost $= 2^{80}$ .
P2WSH / P2TR (SHA-256, $n = 256$ ): collision cost $= 2^{128}$ .

The ratio is: $\frac{2^{128}}{2^{80}} = 2^{48} \approx 2.8 \times 10^{14}$

Concretely, if $2^{80}$ HASH160 collisions take the entire Bitcoin network about one hour, then $2^{128}$ SHA-256 collisions at that same rate would take roughly $2^{48}$ hours ≈ 32 billion years — more than twice the age of the universe.

Question 4 · True or False — Mining ASICs Threaten P2SH Today

Claim: "Bitcoin mining ASICs perform roughly $2^{80}$ hashes per hour, so they can be pointed directly at a P2SH collision attack."

Is this claim true or false?

✅ Correct! ASICs do SHA-256², not HASH160 (SHA-256 + RIPEMD-160), so they can't be directly repurposed for this attack.

❌ Not quite. The hash functions don't match — mining hardware can't directly attack HASH160 even though the work scale is similar.

❌ Not quite. Try again — the hints above can help.

Show solution

Solution:

False.

Mining ASICs compute double SHA-256 ( $\text{SHA256}(\text{SHA256}(x))$ ), which is what Bitcoin's proof-of-work requires. P2SH commitments use HASH160, which is $\text{RIPEMD160}(\text{SHA256}(x))$ — a different hash chain. Mining ASICs have no RIPEMD-160 circuit and therefore cannot directly grind HASH160 collisions.

The real threat is not today's miners. It's that $2^{80}$ operations is now a demonstrably feasible scale for purpose-built custom hardware. The "economically impossible" argument that justified 20-byte hashes in 2012 has eroded, which is precisely why SegWit and Taproot migrated to 32-byte SHA-256 script hashes.

Solved: 0 / 4