BIP16 let a recipient set spending terms, not the sender

Inherited archive entry · retained from the earlier edition. Its factual, legal and policy claims have not all been reverified for 19 September 2026. Research scope.

The problem BIP16 addresses

Before BIP 16, a sender who wanted to pay into a multisignature arrangement had to write out the entire redemption script and embed it in the payment. Gavin Andresen's proposal, dated January 2012, inverts that: a sender pays to the hash of a script, a short twenty-byte value short enough to scan from a QR code, and only the recipient needs to know and later supply the actual script redemption requires. The BIP's own motivation states the benefit directly: funding any arbitrary transaction, no matter how complicated, without the sender needing to understand or construct that complexity at all.

What this changes about who decides custody terms

The practical effect is a shift in who specifies spending conditions. Under the related multisignature standard, BIP 11, an m-of-n arrangement, say two signatures required out of three key holders, was already possible, but making it the sender's problem discouraged its use. Pay-to-script-hash makes the recipient responsible for its own custody design: an exchange, an escrow service or an individual can require multiple signatures to move funds without that requirement ever complicating how anyone pays them. The Bitcoin developer guide now describes script-hash multisig as the standard approach for exactly this reason.

What became expressible, and what did not become automatic

BIP16's rules applied to blocks timestamped from 1 April 2012, once support crossed the network's activation threshold. What changed is expressiveness, not safety: a two-of-three custody arrangement still depends on the key holders storing their keys correctly, coordinating signatures, and not colluding against the remaining party. The protocol change makes such arrangements cheap and standard to fund; it says nothing about whether a particular multisignature setup is well designed, whether its key holders are independent of one another, or whether a service advertising multisig custody actually distributes keys the way it claims. Custody quality remains a question about the specific arrangement, not something the protocol itself certifies.

• Who actually holds each key in a multisignature arrangement, and are they independent parties?
• Does a service's use of a script hash tell a depositor anything about the script behind it?
• What happens to funds if enough key holders in an arrangement lose access at once?

BIP16 solved a narrow protocol problem, letting complex spending conditions travel as a short hash, and that narrow success is often mistaken for a broader guarantee about the custody arrangements it merely made easier to build.