Redeem Script

What Is a Redeem Script?

A redeem script is a piece of Bitcoin Script that specifies the exact conditions under which bitcoin locked in a Pay-to-Script-Hash (P2SH) address can be spent. Rather than embedding complex spending logic directly in the transaction output, P2SH stores only the hash of the redeem script. The full script remains private until someone wants to spend the funds, at which point they must reveal the original redeem script and satisfy its conditions.

This design was introduced by Gavin Andresen in BIP 16, which activated on April 1, 2012. Before P2SH, senders needed to understand and construct complex locking scripts themselves. Redeem scripts shifted that burden to recipients: the sender simply pays to a standard P2SH address (starting with "3"), while the recipient is responsible for constructing and later satisfying the redeem script.

How It Works

The P2SH mechanism operates in two phases: locking (when funds are sent) and unlocking (when funds are spent). The redeem script bridges these phases by acting as both the spending policy and the proof of that policy.

Locking Phase (Sending)

When someone sends bitcoin to a P2SH address, the transaction output contains a simple scriptPubKey that checks a hash:

OP_HASH160 <20-byte-hash-of-redeem-script> OP_EQUAL

The sender does not need to know what the redeem script contains. They only need the recipient's P2SH address, which encodes the 20-byte HASH160 (SHA-256 followed by RIPEMD-160) of the redeem script. This makes all P2SH outputs look identical on chain regardless of the underlying spending conditions.

Unlocking Phase (Spending)

To spend the output, the recipient constructs a scriptSig that includes the data needed to satisfy the redeem script, followed by the serialized redeem script itself:

<signatures or other data> <serialized redeem script>

Bitcoin validates this in three steps:

1. Verify that the scriptSig contains only data-push operations (no executable opcodes allowed before the redeem script)
2. Hash the serialized redeem script with HASH160 and confirm it matches the 20-byte hash in the original scriptPubKey
3. Deserialize the redeem script and execute it as a new script, using the remaining stack items (signatures, public keys, etc.) as input

If the redeem script executes successfully and returns true, the spend is valid. If the hash does not match or the script fails, the transaction is rejected.

A Concrete Example

Consider a 2-of-3 multisig redeem script. The redeem script itself looks like:

OP_2 <PubKey_A> <PubKey_B> <PubKey_C> OP_3 OP_CHECKMULTISIG

The recipient hashes this script, creates a P2SH address from the hash, and shares that address with the sender. To spend, two of the three keyholders provide signatures:

OP_0 <Sig_A> <Sig_B> <serialized redeem script>

The leading OP_0 is a dummy element required by a historical off-by-one bug in OP_CHECKMULTISIG, which consumes one extra stack item beyond the expected count.

Common Redeem Script Types

Multisig Scripts

The most widely used redeem scripts define multisig spending policies. An m-of-n multisig requires m valid signatures from a set of n public keys. Common configurations include 2-of-3 for personal security, 3-of-5 for institutional custody, and 2-of-2 for Lightning payment channels.

P2SH redeem scripts are limited to 520 bytes (the maximum single data push in Bitcoin Script), which caps multisig at approximately 15 public keys when using compressed keys (33 bytes each).

Time-Locked Scripts

Time-locked redeem scripts restrict spending until a certain time or block height has passed. Two opcodes enable this:

• OP_CHECKLOCKTIMEVERIFY (CLTV): enforces an absolute timelock, preventing spending until a specific block height or Unix timestamp
• OP_CHECKSEQUENCEVERIFY (CSV): enforces a relative timelock, requiring a certain number of blocks to pass after the UTXO is confirmed before it can be spent

These are commonly combined with signature checks to create vesting schedules, inheritance plans, or refund paths.

Hash Time-Locked Contracts (HTLCs)

HTLCs combine hash locks and time locks into a single redeem script with two spending paths. Defined in BIP 199, the structure uses OP_IF branching:

OP_IF
    OP_SHA256 <digest> OP_EQUALVERIFY
    OP_DUP OP_HASH160 <seller_pubkey_hash>
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    OP_DUP OP_HASH160 <buyer_pubkey_hash>
OP_ENDIF
OP_EQUALVERIFY OP_CHECKSIG

This creates two ways to spend:

• Hash-lock path: the recipient reveals the preimage that hashes to the digest, plus a valid signature
• Time-lock path: after the timeout expires, the sender reclaims the funds with their signature

HTLCs are the foundation of Lightning Network channels, atomic swaps, and submarine swaps.

P2WSH: The SegWit Evolution

SegWit (BIP 141), activated in August 2017, introduced Pay-to-Witness-Script-Hash (P2WSH) as the native successor to P2SH for complex scripts. In P2WSH, the script that defines spending conditions is called a "witness script" rather than a "redeem script," but it serves the same logical role.

The larger hash in P2WSH provides significantly stronger security against collision attacks, and the witness discount reduces transaction fees by treating witness data as less costly. P2WSH also lifts the 520-byte script size limit to 10,000 bytes, enabling more complex spending conditions.

Wrapped SegWit: The Transition Format

During the transition to SegWit, a hybrid format emerged: P2SH-P2WSH. In this format, the redeem script is simply the SegWit witness program itself (e.g., OP_0 <32-byte-SHA256-hash>), wrapping a P2WSH output inside a P2SH address. This allowed older wallets that only understood P2SH addresses to send to SegWit recipients. While still functional, this wrapped format is now considered legacy as native SegWit and Taproot adoption have grown.

Why It Matters

Redeem scripts introduced a fundamental shift in how Bitcoin handles complex transactions. Before P2SH, the sender had to construct the full locking script, meaning they needed to understand the recipient's spending policy. This was impractical for anything beyond simple single-signature payments.

With redeem scripts, recipients define their own spending conditions and share only a standard-looking address. This separation enabled the practical deployment of multisig wallets, time-locked contracts, and cross-chain swaps. Every Lightning channel opened before Taproot relied on a redeem script (or witness script) containing a 2-of-2 multisig with timelocked revocation paths.

For Bitcoin Layer 2 protocols like Spark, the scripting foundations that redeem scripts established remain essential. Modern protocols build on the same primitives (hash locks, time locks, multisig) whether they use P2SH, P2WSH, or P2TR outputs.

Taproot: Beyond Redeem Scripts

Taproot (BIP 341), activated in November 2021, represents the next evolution beyond redeem scripts. Instead of revealing the entire script at spend time, Taproot uses Schnorr signatures and Merkelized Abstract Syntax Trees (MAST) to commit multiple script branches into a Taproot tree. Only the branch actually used for spending is revealed on chain; all other branches remain hidden.

This provides two key advantages over traditional redeem scripts:

• Privacy: unused spending conditions are never exposed, so observers cannot determine what other paths were available
• Efficiency: in the common cooperative case (key-path spend), no script is revealed at all, making the transaction indistinguishable from a simple single-signature payment

Risks and Considerations

Hash Collision Vulnerability

P2SH uses a 160-bit hash (HASH160), which provides only 2^80 collision resistance under birthday attacks. While no practical collision has been demonstrated, this is below modern cryptographic standards. High-value multisig setups should prefer P2WSH (256-bit hash with 2^128 collision resistance) or P2TR for stronger security guarantees.

Script Size Limitations

The 520-byte limit on P2SH redeem scripts constrains what can be expressed in a single script. Complex policies involving many participants, multiple spending paths, or large data commitments may exceed this limit. P2WSH raises the limit to 10,000 bytes, and Taproot effectively removes it for practical purposes by splitting conditions across a Merkle tree.

On-Chain Privacy

When a P2SH output is spent, the full redeem script is published on chain. This reveals the complete spending policy to anyone performing chain analysis: how many signers were involved, what timelocks were set, and what type of contract was used. This metadata leakage makes P2SH transactions easily fingerprinted compared to Taproot, where only the executed branch is visible.

Address Reuse Risks

Reusing a P2SH address after spending from it once exposes the redeem script to anyone watching the blockchain. Future deposits to the same address are then vulnerable if the redeem script's conditions become easier to satisfy over time (for example, if a timelock has expired). Address reuse should be avoided for any script-based output.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.