Redeem script

BIP-16 let a sender pay a 20-byte hash instead of a whole contract, and the redeem script is the contract that hash stands for. It has to fit in one stack element, so 520 bytes is the hard ceiling. Lose those bytes and your private keys are worthless, which makes the redeem script part of your backup rather than part of your software.

How it works

A redeem script is invisible while the coins sit still. The output that holds them contains only a hash and a pattern that consensus recognises, enforced across the network from April 1, 2012 at block 173,805. Nobody paying you learns anything about the conditions, and neither does a block explorer.

Revealing it happens in the spend. The signature script pushes whatever arguments the contract needs and finishes with the serialized contract itself. A validating node takes that last item, hashes it, compares the result with the hash in the output, and only then deserializes the item and runs it as code against the remaining stack. Both stages must pass, and because the field carrying it may contain nothing but pushes, the script itself cannot smuggle in behaviour before it is checked.

The most common redeem script in existence is not a contract at all. From 2017 onward, wallets that wanted SegWit savings while remaining payable by old software wrapped a witness program in a script hash, so the redeem script is 22 bytes: a version byte and a 20-byte key hash, with nothing to execute. Millions of exchange withdrawal addresses beginning with 3 hide exactly that and nothing more.

Where you see it

Bitcoin Core hands one to you whenever you build a script address, and its decodescript command turns the hex back into readable assembly. In a descriptor the script is written explicitly as sh(wpkh(...)) or sh(multi(...)), which is the modern way to record it, because descriptor wallets arrived in Bitcoin Core 0.21.0 in January 2021 and made the old habit of importing bare addresses obsolete.

The loss mode is real and it is specific. A seed phrase regenerates keys. It does not regenerate an arbitrary script, and it cannot tell you the other cosigners' public keys, so a 2-of-3 arrangement where every participant has kept only their own seed is unspendable. People have lost coins holding a complete set of private keys and no record of the script those keys were arranged into. Store the descriptor with each seed backup, and restore from it once, on a small amount, before the address holds anything you would miss.

The other thing to know is the sizing limit. Fifteen compressed public keys plus their push prefixes and the surrounding opcodes come to 513 bytes, which just fits; a sixteenth does not. That ceiling, rather than any rule about multisig, is what caps a script address at fifteen cosigners.

Redeem script vs Witness script

A redeem script and a witness script occupy the same conceptual slot in two different eras, and the difference is where the bytes travel and how they are committed. A redeem script is committed with a 160-bit hash and rides in the signature script at four weight units per byte. A witness script is committed with a full 256-bit SHA-256 and rides in the witness at one weight unit per byte, which is why the same policy costs roughly a quarter as much to spend. A nested arrangement uses both at once: the redeem script is the 34-byte witness program and the witness script is the actual contract. If you are recording a backup for a wrapped SegWit multisig, you need both of them written down, not one.