BIP 0016
How can a script hide behind a hash?
A pay-to-script-hash output commits to a 20-byte hash. The conditions behind it stay off chain until someone spends the coin, and then they have to match exactly.
Suppose a coin should need two signatures out of two keys. Someone has to write those conditions into the output that receives it, and without P2SH that someone is the sender. The alternative BIP 16 weighed was simply giving the sender the complete script.12
BIP 16, assigned in 2012 and recorded as deployed, turned that around. The sender pays to a fixed-length 20-byte hash of a script. The receiver keeps the script and reveals it only when spending. The author’s stated purpose was to move responsibility for the spending conditions from the sender to the redeemer.134
Source details
This chapter is an independent explanation, not the proposals themselves. Preamble fields are shown as recorded in the pinned files, with author e-mail addresses omitted. Status is the proposal’s own field, not an endorsement or a sign of consensus.
BIP 16: Pay to Script Hash
- BIP
- 16
- Layer
- Consensus (soft fork)
- Title
- Pay to Script Hash
- Authors
- Gavin Andresen
- Status
- Deployed
- Type
- Specification
- Assigned
- 2012-01-03
On chain when the coin is created
a9 14 0fb9463421696b82c833af241c78c17ddbde4934 87OP_HASH160, a 20-byte push, OP_EQUAL: 23 bytes, whatever the conditions are.
Revealed in the spending scriptSig
OP_2 <33 bytes> <33 bytes> OP_2 OP_CHECKMULTISIG5221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae71 bytes; RIPEMD-160(SHA-256(script)) = 0fb9463421696b82c833af241c78c17ddbde4934
BIP 174 line 833 (BIP 174 input 0). Hash computed at build time and matched against the output.
A fixed shape
Every P2SH output has the same three parts: OP_HASH160, a push of exactly 20 bytes, and OP_EQUAL. That is 23 bytes whether the hidden conditions are one key or fifteen. A spend supplies the signatures or other data the script needs, followed by the script itself, serialized as one more piece of pushed data. BIP 16 calls that last item the redeemScript.258
The BIP’s own example is the simplest case: a script that checks one signature against one key. The output holds the 20-byte hash of that script, and the spending scriptSig holds a signature and the script. Nothing in the output says what kind of script it is, or how many keys it has.19
The responsibility BIP 16 moves is real. The sender needs only the 20 bytes. The receiver must keep the full script, because no spend is possible without supplying it exactly: the scriptSig has to carry the very bytes that hash to the output’s value, and they then have to run successfully.1210
The 20 bytes are the HASH160 of the script. This site’s model computes it as RIPEMD-160 of SHA-256, and the figure above recomputes it for real spends and compares it with the output byte for byte.57
Checked twice
BIP 16 gives the rules as three steps. First, the scriptSig may contain nothing but push operations; anything else fails. Second, normal validation runs: the pushed items become the stack, the output’s script hashes the top item, and validation fails at once if that hash differs from the one in the output.10
Third, and only for these outputs, the serialized script is popped off the stack, decoded, and run against whatever is left. The coin moves only if that second run also succeeds. The same pushed bytes are used twice: once as data to be hashed, once as a program.10
Step through the three published spends below. In the legacy 2-of-2, the redeem script is a CHECKMULTISIG over two keys, and each signature must match a key in order. The tests behind this page swap the two signatures and the spend fails, even though both are valid signatures by the right keys. CHECKMULTISIG also takes one extra item off the stack; in this spend it is empty.711
A · Interactive
Static view: the first spend with every stage shown. With JavaScript you can switch spends, hide the redeem script and step through the stages.
OP_HASH160 <0fb94634…de4934> OP_EQUALOP_2 <33 bytes> <33 bytes> OP_2 OP_CHECKMULTISIG- 01The scriptSig only pushes data
scriptSig: OP_0 <71 bytes> <72 bytes> <71 bytes>4 pushes; the last is the serialized redeem script - 02Its hash matches the output
scriptPubKey: OP_HASH160 <20 bytes> OP_EQUALstack:(empty)30440220…118c0130450221…06ea0152210295…d752aeOP_HASH160replace the top item with RIPEMD-160(SHA-256(item))<20-byte push>push 20 bytesOP_EQUALthe two items are equal: push 1
- 03The redeem script runs on the remaining stack
runs: OP_2 <33 bytes> <33 bytes> OP_2 OP_CHECKMULTISIGstack:(empty)30440220…118c0130450221…06ea01OP_2push the number 2<33-byte push>push 33 bytes<33-byte push>push 33 bytesOP_2push the number 2OP_CHECKMULTISIG2-of-2: every signature matches a key, in order; also pops one extra item (here it is empty) · sig 1 → key 1, sig 2 → key 2
Source: BIP 174 line 833. Recorded at build time; signatures verified against digests computed by the tested model. BIP 16 sigops counted for this redeem script: 2.
B · Worked example
The published spend Legacy P2SH 2-of-2 (BIP 174 input 0), checked the way BIP 16 describes. The hatched layer is the hash check.
The output commits to a 20-byte hash
- scriptPubKey (23 bytes)
a9140fb9463421696b82c833af241c78c17ddbde493487
The spend's scriptSig only pushes data: 4 pushes; the last is the serialized redeem script
- pushes
(empty) · 71 bytes · 72 bytes · 71 bytes
Hash the last push and compare
- HASH160(redeem script)
0fb9463421696b82c833af241c78c17ddbde4934- hash in the output
0fb9463421696b82c833af241c78c17ddbde4934
Equal, so the output really committed to this script.
Run the redeem script on the remaining stack
- redeem script
OP_2 <33 bytes> <33 bytes> OP_2 OP_CHECKMULTISIG
Each signature must match a key, in order: signature 1 → key 1, signature 2 → key 2.
Source: BIP 174 line 833; recorded by the tested P2SH model, signatures verified with noble.
Each stage can fail on its own. Change one byte of the redeem script inside the scriptSig and the hash no longer matches: the second stage stops the spend before the script ever runs. Put a non-push opcode into the scriptSig and the first stage stops it.1013
A wrapper for SegWit
When SegWit arrived, BIP 141 reused this envelope. If the redeem script is exactly a witness version and a witness program, the output is a P2SH witness program: the scriptSig must hold nothing but that one push, and the real conditions move into the witness.12
Two of the figure’s spends work this way. In the P2SH-wrapped P2WPKH from BIP 143, the redeem script is a 22-byte program naming a key hash; the witness holds a signature and the key. In the P2SH-wrapped P2WSH from BIP 174, the redeem script is a 34-byte program naming a script hash, and the witness holds the 2-of-2 script itself. Their signatures commit to the BIP 143 digest, not the original one.6712
The difference shows in where the bytes sit. The legacy 2-of-2 puts 218 bytes in its scriptSig. The wrapped 2-of-2 needs a 35-byte scriptSig, and its witness serializes to 218 bytes. Since weight counts a byte outside the witness four times and a witness byte once, that comes to 872 weight units against 358, so moving the signatures makes the wrapped spend lighter.1415
Legacy P2SHscriptSig 218 B · witness none · 872 WU
P2SH-P2WSHscriptSig 35 B · witness 218 B · 358 WU
P2SH-P2WPKHscriptSig 23 B · witness 107 B · 199 WU
scriptSig: 4 weight units per bytewitness: 1 weight unit per byte
Bar length is weight units. scriptSig: the script’s bytes, push opcodes included. Witness: as serialized, with the item count and each item’s length prefix. Neither includes the rest of the input (outpoint, nSequence, the scriptSig’s own length byte). From the pinned transactions.
The wrapper had a practical reason. BIP 141 lists, among the things a wallet that never upgraded can still do, sending bitcoin to upgraded wallets using a P2SH address. The payer sees an ordinary P2SH output; only the spender has to understand the witness.1216
Wrapped SegWit is still not native SegWit. The output is an ordinary 23-byte P2SH output and the scriptSig is not empty. BIP 141 notes that native P2WSH outputs use 34 bytes instead, and its authors chose the longer hash for better resistance to collision attacks.812
Limits and history
Because the redeem script travels as pushed data, it obeys the 520-byte limit on any push. BIP 16 works the consequence through for multisig with 33-byte keys: three bytes plus 34 per key allows at most 15 keys, 513 bytes in all.17
Signature operations inside the redeem script still count toward the block’s limit, by scanning rather than running: one per CHECKSIG, the key count for a CHECKMULTISIG preceded by OP_1 to OP_16, and 20 otherwise. The BIP’s examples come to 3 and 22. The author explains that the counting is meant to be quick, and that the per-block limit protects miners from blocks crafted to be slow to validate.1819
The rest is history the BIP records. It replaced an earlier proposal, BIP 12’s OP_EVAL, and the author describes recognizing one special output form as ugly, but less so than the alternatives. Its rollout asked miners to mark their blocks with /P2SH/, and its rules were to apply to blocks timestamped from 1 April 2012; some earlier transactions in the chain fail them. Old nodes, the BIP notes, check only that the hash matches, which is why it also discusses a costly one-confirmation attack against them.20212223
The rollout plan in the text is concrete. To avoid a lasting split, more than half of miners had to switch to the new rules at once. On 1 February 2012 the previous week’s blocks would be counted: with 550 or more of roughly 1,000 carrying /P2SH/, full validation would start for blocks after 15 February. The rule section, as recorded, names 1 April 2012 instead; the BIP keeps both dates, and this chapter does not try to reconcile them. To old software, meanwhile, these spends were non-standard: it would typically neither relay nor mine them.212425
One more distinction matters. BIP 16 says spends are only standard, meaning relayed and mined by default, if the redeem script is itself one of the standard script types. That was relay policy as BIP 16 states it, separate from the three validation rules that decide whether a block containing the spend is valid.26
Evidence
Each numbered marker in the text points here, and the ↩ links lead back to every place that cites an entry. Quotes are verbatim from the BIP files at commit
3a10b5b, including their wiki markup; links open
the exact lines; the quoted text sits under each entry. Labels say what kind of statement each is: a rule, the author’s rationale, history,
a test vector, or our own inference.
-
↩ a b c d Author’s rationale The author's aim is to move the job of supplying spending conditions from the sender to the redeemer, so a sender can fund any transaction, however complex, with a fixed 20-byte hash. The BIP records that some felt P2SH unnecessary, preferring to give the sender the complete script.
BIP 16 L17 BIP 16 L19 BIP 16 L66
Quoted source text (3)
The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer.
The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.
several people feel that it is unnecessary, and complex/multisignature transaction types should be supported by simply giving the sender the complete {serialized script}.
-
↩ a b c d e Rule It is redeemed by a scriptSig of signatures followed by the serialized script, also called the redeemScript.
Quoted source text (2)
...signatures... {serialized script}
the ''serialized script'' - also referred to as the ''redeemScript'' -
-
↩ History BIP 16 is a consensus soft-fork proposal by Gavin Andresen, assigned in 2012; its preamble records the status Deployed.
BIP 16 L3 BIP 16 L5 BIP 16 L6 BIP 16 L8
Quoted source text (4)
Layer: Consensus (soft fork)
Authors: Gavin Andresen
Status: Deployed
Assigned: 2012-01-03
-
↩ Rule BIP 16 describes a new standard transaction type and additional validation rules that apply only to it.
Quoted source text (1)
This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions.
-
↩ a b c Rule A P2SH output's script is OP_HASH160, a push of exactly 20 bytes, and OP_EQUAL.
Quoted source text (1)
OP_HASH160 [20-byte-hash-value] OP_EQUAL [20-byte-hash-value] shall be the push-20-bytes-onto-the-stack opcode (0x14) followed by exactly 20 bytes.
-
↩ a b c Test vector BIP 174's published role trace ends in a transaction whose first input spends a legacy P2SH 2-of-2 multisig and whose second spends a P2SH-wrapped P2WSH 2-of-2; BIP 143 publishes a P2SH-wrapped P2WPKH example.
BIP 174 L833 BIP 143 L203 BIP 143 L215–216
Quoted source text (3)
0200000000010258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd75
=== P2SH-P2WPKH ===
scriptPubKey : a9144733f37cf4db86fbc2efed2500b4f4e49f31202387, value: 10 redeemScript : 001479091972186c449eb1ded22b78e40d009bdf0089
-
↩ a b c d e Test vector For all three pinned spends, this site's model finds the scriptSig push-only and the redeem script's HASH160 (computed as RIPEMD-160 of SHA-256) equal to the output's, and every signature verifies (with noble) against the digest the model computes: the original digest for the legacy spend, BIP 143's for the wrapped ones.
Quoted source text (1)
# Validation fails if there are any operations other than "push data" operations in the scriptSig.
-
↩ a b Author’s rationale BIP 141 notes that a native P2WSH output takes 34 bytes against BIP 16's 23, a size its authors chose for better collision resistance.
Quoted source text (1)
The scriptPubKey occupies 34 bytes, as opposed to 23 bytes of BIP16 P2SH. The increased size improves security against possible collision attacks, as 280 work is not infeasible anymore
-
↩ Rule The BIP's example is a one-signature script: the scriptSig holds a signature and the serialized {pubkey OP_CHECKSIG}, and the output holds its 20-byte hash.
Quoted source text (1)
scriptSig: [signature] {[pubkey] OP_CHECKSIG} scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL
-
↩ a b c d e f Rule Validation fails if the scriptSig has anything but push operations; normal validation then hashes the serialized script and fails at once if it does not match the output; finally the serialized script is popped and the transaction is validated again with the remaining stack and the deserialized script.
Quoted source text (1)
# Validation fails if there are any operations other than "push data" operations in the scriptSig. # Normal validation is done: an initial stack is created from the signatures and {serialized script}, and the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint. # {serialized script} is popped off the initial stack, and the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.
-
↩ a b Test vector In the legacy 2-of-2 spend, signature 1 matches key 1 and signature 2 matches key 2; with the two signatures swapped the redeem script fails, because CHECKMULTISIG checks keys in order. CHECKMULTISIG also pops one extra item, which here is empty.
Quoted source text (1)
the transaction is validated again using the popped stack and the deserialized script as the scriptPubKey.
-
↩ a b c d e f Rule Under BIP 141, if the redeemScript is exactly a witness version byte plus a witness program, it is a P2SH witness program: the scriptSig must be exactly a push of the redeemScript, and the witness carries the rest.
Quoted source text (1)
Triggered when a <code>scriptPubKey</code> is a P2SH script, and the BIP16 <code>redeemScript</code> pushed in the <code>scriptSig</code> is exactly a push of a version byte plus a push of a witness program. The <code>scriptSig</code> must be exactly a push of the BIP16 <code>redeemScript</code> or validation fails.
-
↩ Test vector Changing one byte of the redeem script inside the scriptSig makes its hash differ from the output and validation fails at the second stage; adding a non-push opcode to the scriptSig fails the first.
Quoted source text (1)
the hash of the script is computed and validation fails immediately if it does not match the hash in the outpoint.
-
↩ a b Test vector Measured on the pinned transactions: the legacy spend's scriptSig is 218 bytes with an empty witness; the P2SH-P2WSH spend's scriptSig is 35 bytes and its witness serializes to 218 bytes (item count and length prefixes included); the P2SH-P2WPKH spend's are 23 and 107. Counting scriptSig bytes four times and witness bytes once gives 872 against 358 weight units for the two 2-of-2 spends.
Quoted source text (1)
''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size''
-
↩ a b Rule Transaction weight is base size × 3 plus total size, so a byte outside the witness counts four times and a witness byte once.
Quoted source text (1)
''Transaction weight'' is defined as ''Base transaction size'' * 3 + ''Total transaction size''
-
↩ Rule BIP 141 lists sending to upgraded wallets using a P2SH address among the things a non-upgraded wallet can still do.
Quoted source text (2)
What a non-upgraded wallet can do
Sending bitcoin to upgraded wallets using a P2SH address
-
↩ Rule Because the serialized script is pushed like any other data, it cannot exceed 520 bytes, so a P2SH multisig with 33-byte keys can have at most 15 keys: 3 + 15 × 34 = 513 bytes.
Quoted source text (2)
no data greater than 520 bytes may be pushed to the stack. Thus it is not possible to spend a P2SH output if the redemption script it refers to is >520 bytes in length.
it is only possible to spend a P2SH output requiring a maximum of 15 pubkeys to redeem: 3 bytes + 15 pubkeys * 34 bytes/pubkey = 513 bytes
-
↩ Rule Signature operations in the serialized script count toward the block limit: CHECKSIG as 1, CHECKMULTISIG after OP_1–OP_16 as that number, and any other CHECKMULTISIG as 20, whether or not they run; the BIP's examples count 3 and 22.
BIP 16 L48–52 BIP 16 L56–57 BIP 16 L59–60
Quoted source text (3)
Signature operations in the {serialized script} shall contribute to the maximum number allowed per block (20,000) as follows: # OP_CHECKSIG and OP_CHECKSIGVERIFY count as 1 signature operation, whether or not they are evaluated. # OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY immediately preceded by OP_1 through OP_16 are counted as 1 to 16 signature operation, whether or not they are evaluated. # All other OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY are counted as 20 signature operations.
+3 signature operations: {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}
+22 signature operations: {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
-
↩ Author’s rationale The author explains the counting rule is meant to be quick to apply by scanning the script, and that the block limit guards miners against denial-of-service blocks.
Quoted source text (1)
The signature operation counting rules are intended to be easy and quick to implement by statically scanning the {serialized script}. Bitcoin imposes a maximum-number-of-signature-operations per block to prevent denial-of-service attacks on miners.
-
↩ Author’s rationale BIP 16 replaced BIP 12's proposed OP_EVAL; the author describes recognizing one special output form as ugly but less so than the alternatives, and notes the motivation was controversial.
BIP 16 L64 BIP 16 L66 BIP 16 L68
Quoted source text (3)
This BIP replaces BIP 12, which proposed a new Script opcode ("OP_EVAL") to accomplish everything in this BIP and more.
The Motivation for this BIP (and BIP 13, the pay-to-script-hash address type) is somewhat controversial
Recognizing one 'special' form of scriptPubKey and performing extra validation when it is detected is ugly. However, the consensus is that the alternatives are either uglier, are more complex to implement, and/or expand the power of the expression language in dangerous ways.
-
↩ a b History BIP 16 says its rules should apply only to blocks with timestamps from 1 April 2012, and that earlier transactions in the chain fail them; its rollout plan counted blocks carrying "/P2SH/" in the coinbase.
BIP 16 L41 BIP 16 L41 BIP 16 L94
Quoted source text (3)
These new rules should only be applied when validating transactions in blocks with timestamps >= 1333238400 (Apr 1 2012)
There are transactions earlier than 1333238400 in the block chain that fail these new validation rules.
miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.
-
↩ Rule Old implementations check only that the serialized script's hash matches, and do no other validation, when they validate blocks from upgraded software.
Quoted source text (1)
Old implementations will validate that the {serialize script}'s hash value matches when they validate blocks created by software that fully support this BIP, but will do no other validation.
-
↩ Author’s rationale The BIP describes a 1-confirmation attack on old implementations, which the author judges expensive and difficult in practice.
Quoted source text (1)
There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice.
-
↩ History To avoid a lasting split, BIP 16 says more than 50% of miners had to enforce the new rules at the same time; its plan was to count blocks marked /P2SH/ over the week before 1 February 2012 and, with 550 or more of roughly 1,000, fully validate these spends in blocks after 15 February 2012.
Quoted source text (2)
more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated.
-
↩ Rule To old implementations these transactions are non-standard, so they typically neither relay nor mine them.
Quoted source text (1)
These transactions are non-standard to old implementations, which will (typically) not relay them or include them in blocks.
-
↩ History Spends of these outputs are only considered standard if the redeemScript is itself one of the other standard types.
Quoted source text (1)
Transactions that redeem these pay-to-script outpoints are only considered standard if the ''serialized script'' - also referred to as the ''redeemScript'' - is, itself, one of the other standard transaction types.