MASTERING-BITCOIN · Interactive Practice | Unit 8 · Video 1

The Witness That Left the Room: SegWit Transactions

IKey Reference

Output Type	Output Script	Program Length	Hash Used
Legacy P2PKH	`OP_DUP OP_HASH160 <20B> OP_EQUALVERIFY OP_CHECKSIG`	20 bytes	RIPEMD160(SHA256)
Legacy P2SH	`OP_HASH160 <20B> OP_EQUAL`	20 bytes	RIPEMD160(SHA256)
P2WPKH	`<0x00> <20B>`	20 bytes	RIPEMD160(SHA256) of pubkey
P2WSH	`<0x00> <32B>`	32 bytes	SHA256 of script

The SegWit Pattern: witness version byte + witness program (data push). Length alone disambiguates P2WPKH (20B) from P2WSH (32B).

Soft Fork Trick: The output script <0x00><20B> looks like "anyone-can-spend" to a 2014 node — two pushes leaving a truthy stack. Upgraded nodes enforce real signature checks via the witness.

IIInteractive Visualizations

Visualization 1: Where Does the Signature Live?

A legacy P2PKH spend keeps the signature inside the transaction body (in scriptSig), so the signature contributes to the transaction ID. SegWit moves the signature outside into a separate witness structure that does NOT contribute to the txid — eliminating signature malleability.

Toggle the mode below to see how the same signature data lives in different places.

⚙ interactive visualization — coming to this page format soon

Reflect: In the SegWit view, the input's scriptSig is empty and the signature data sits in a separate panel attached to (but not part of) the transaction body. This is the "segregation" in Segregated Witness.

Visualization 2: Length Disambiguates P2WPKH from P2WSH

Both native SegWit outputs share the same shape: <version byte> <data push>. With witness version 0x00, the length of the program is the only discriminator. 20 bytes → P2WPKH (single key). 32 bytes → P2WSH (script).

Drag the slider to set a witness program length and watch the interpretation change.

⚙ interactive visualization — coming to this page format soon

Notice: Only 20 and 32 are valid for witness version 0. Future witness versions (like Taproot's v1) can claim other lengths and define new rules without disturbing v0 spends.

Visualization 3: Collision Resistance — P2SH vs P2WSH

P2SH commits to a script with RIPEMD160(SHA256(script)) — a 20-byte digest with roughly 80 bits of collision resistance (birthday bound). P2WSH uses raw SHA256(script) — 32 bytes, 128 bits of collision resistance.

For complex scripts where attackers might grind alternative scripts that hash to the same value, this jump matters a lot. The bars below are on a log scale to fit the difference on screen.

⚙ interactive visualization — coming to this page format soon

Reflect: 80 bits of collision resistance was once considered acceptable, but it is within reach of well-funded attackers grinding scripts. P2WSH's 128-bit security gives a comfortable margin — same upgrade pattern, stronger cryptographic foundation.

IIIQuiz Questions

Question 1

A native SegWit P2WPKH output script consists of just two pushes: <0x00> <20-byte hash>. To a node from 2014 that does not understand SegWit, how does this script evaluate?

✅ Correct! Two pushes leave a truthy stack — the old node sees it as valid (anyone-can-spend), but upgraded nodes enforce the real signature check via the witness.

❌ Not quite. Remember that the old node literally just executes the two pushes and checks whether the top of the stack is truthy.

Show solution

Solution:

To a pre-SegWit node, <0x00> <20-byte hash> is just two data pushes. After execution the stack contains a non-empty (truthy) value on top, so by the old consensus rules the script is valid — it looks like an anyone-can-spend output.

That's exactly why SegWit is a soft fork: the new rules are a tightening of consensus that old nodes still accept. SegWit-aware miners and economic nodes enforce the real signature check via the witness, so theft attempts never make it into blocks.

Question 2

A node receives a witness-version-0 output. The witness program after the version byte is 32 bytes long. How does the node interpret this output?

✅ Correct! 32 bytes after a 0x00 version byte means P2WSH — the witness must reveal the script.

❌ Not quite. Both v0 lengths are valid: 20 bytes is P2WPKH and 32 bytes is P2WSH. Length alone tells the node which.

Show solution

Solution:

Under witness version 0, length is the only discriminator:

20 bytes → P2WPKH: program is HASH160(pubkey). The witness contains <sig> <pubkey>; the node verifies the signature against the pubkey.
32 bytes → P2WSH: program is SHA256(script). The witness contains the unlocking inputs followed by the actual script. The node checks SHA256(script) == program, then executes the script with its inputs.

Taproot is witness version 1, not 0, so it doesn't apply here.

Question 3

True or False: A spender can safely save fees by automatically converting the receiver's legacy P2PKH address into a P2WPKH address (using the same 20-byte hash) without asking the receiver.

✅ Correct! The hash may match, but the receiver's wallet may not understand SegWit and the source key may be uncompressed — both of which break the spend.

❌ Not quite. Even though the 20-byte hash is the same, auto-converting risks locking the receiver's funds and may violate SegWit's compressed-key requirement.

Show solution

Solution: False.

Only the receiver should construct a SegWit address. Two things can go wrong if a spender auto-converts:

Wallet incompatibility. If the receiver's wallet doesn't understand SegWit, they can't recognize or spend the output. Funds are stuck — possibly forever.
Uncompressed-key origin. Legacy P2PKH addresses can be derived from uncompressed public keys. SegWit consensus rules forbid uncompressed keys in version-zero programs. The hash might match by coincidence, but any spend attempt would fail (and a future soft fork could make such outputs strictly unspendable).

The rule is receiver-only: the recipient publishes their SegWit address explicitly, derived from a compressed pubkey, or it doesn't exist.

Question 4

Bob wants to receive SegWit-discounted payments, but Alice's old wallet only understands legacy address formats (addresses starting with 1 or 3). What is the role of P2SH-nested SegWit in solving this?

✅ Correct! P2SH-nesting wraps the SegWit witness program in a familiar 3... address, giving full backward compatibility while still applying SegWit's spending rules and discount.

❌ Not quite. The whole point of nesting is that Alice doesn't need to upgrade — Bob's SegWit program is hidden inside a standard P2SH address she already understands.

Show solution

Solution:

P2SH-nested SegWit is the compatibility bridge that let the network adopt SegWit incrementally:

Bob's wallet computes the witness program: <0x00> <HASH160(compressed pubkey)>.
It hashes that whole 22-byte program with HASH160 again and wraps the result as a standard P2SH address (starts with 3...).
Alice's old wallet sees a normal P2SH address and pays it like any other.
When Bob spends, his scriptSig contains just the witness program itself (which satisfies the outer P2SH check). The actual signature and pubkey travel in the witness structure, so Bob still gets the fee discount and malleability fix.

The same trick works for multisig (P2WSH nested in P2SH). One important caveat: a 3... address tells you nothing about whether the recipient is SegWit-capable — it could be classic P2SH multisig or nested SegWit.

Solved: 0 / 4