P2SH (Pay-to-Script-Hash): The Anchor Guide to "3" Addresses

🔍 Why This Module Matters

Before 2012, if you wanted to use Multisig, you had to ask the person sending you money to do extra work and pay extra fees. P2SH fixed this "Sender Burden." It is the reason we can have complex vault systems and hardware wallet multisigs that look just like a regular payment to the outside world. This module will deconstruct the "Redeem Script" logic, explain the soft fork that made P2SH possible, and show why hashing a script is the key to Bitcoin's scalability and privacy.

🏛️ The Great Responsibility Shift: Sender vs. Recipient

In the legacy model (P2PK/P2MS), the sender had to know the locking rules.

1. The Legacy Burden

If you had a 2-of-3 multisig wallet, you had to give the sender all three of your public keys.

• The Sender Paid: For the extra bytes required to store those keys.

• The Privacy Was Zero: Everyone could see your internal wallet structure immediately.

2. The P2SH Solution

With P2SH, the recipient provides a single address (starting with 3).

• The Sender Pays: A flat, small fee for a standard 20-byte hash payment.

• The Privacy is High: The world only knows that there is a script, but they don't know if it's a multisig, a timelock, or something else until you spend it.

⚙️ The "Redeem Script": The Secret Instructions

In P2SH, the actual spending rules are contained in a Redeem Script.

1. Creation: You create your script (e.g., OP_2 <Key A> <Key B> <Key C> OP_3 OP_CHECKMULTISIG).

2. Hashing: You hash that script using HASH160.

3. Encoding: You turn that hash into a "3" address.

4. Spending: When you want to move the funds, you must provide the Full Raw Redeem Script in your transaction input. The node then checks if the script hashes to the value in the address and executes it.

graph LR
 A[Redeem Script] -->|HASH160| B[20-Byte Script Hash]
 B -->|Base58Check| C[Address Starting with 3]
 style C fill:#f96,stroke:#333,stroke-width:4px

🛠️ Comparison: Why P2SH Won

🛡️ The "Soft Fork" Magic of BIP 16

P2SH was a backward-compatible upgrade.

• Old Nodes: Saw the script as OP_HASH160 <Hash> OP_EQUAL. They thought: "If the user provides something that hashes to this, the spend is valid." They didn't actually execute the inner script.

• New Nodes: Recognized the specific P2SH pattern. They performed the hash check AND then executed the resulting Redeem Script.

• Security: Because the majority of miners upgraded, any attempt to provide a "garbage" script that merely hashed correctly but failed the logic was rejected by the network.

🎯 Learning Objectives for this Module

By the end of this module, you will be able to:

1. Define P2SH and identify its standard address prefix.

2. Explain how P2SH moves complexity from the sender to the recipient.

3. Describe the role of the "Redeem Script" in the spending process.

4. Identify two privacy benefits of using hashed scripts over bare scripts.

5. Understand the soft fork mechanism that allowed old nodes to stay in sync.

🗺️ Module Roadmap: What's Next?

Now that we've hashed the script, we will look at its execution:

1. P2SH ScriptPubKey Structure: Deconstructing the OP_HASH160 command.

2. The Redeem Script: A technical walkthrough of internal serialization.

3. P2SH Efficiency & Privacy: Calculating the costs of complex spends.

4. Python P2SH Auditor: Writing a script to derive a "3" address from a raw multisig script.

🎓 Summary

P2SH is the "Enabler" of Bitcoin's smart contract ecosystem. It proved that the network could support complex, multi-signature, and time-locked ownership without sacrificing usability or blockspace efficiency. By mastering P2SH, you are understanding the bridge that moved Bitcoin from a simple "Coin Transfer" system into a robust, programmable financial platform.