P2SH

Pay To Script Hash

P2SH is a locking script that allows you to lock up bitcoins to the hash of a script.

This allows you to use custom locking scripts for your bitcoins, whilst also allowing you to provide the sender with an address to send the bitcoins to (instead of them having to use the full custom locking script).

The full custom locking script is referred to as the Redeem Script, and is revealed when you come to spend the bitcoins later on.

So in short, P2SH is a practical solution for placing custom locking scripts on bitcoins. It's most commonly used for locking up bitcoins to complex locking scripts, such as P2MS.

Legacy Script. This is a legacy script pattern. It's still used occasionally, but P2WSH is now the preferred choice (which works in the same way).

Usage

How does P2SH work?

ScriptPubKey

The P2SH locking script contains the hash of another locking script (Script Hash), surrounded by the HASH160 and EQUAL opcodes.

Here's an example of a ScriptPubKey for a P2SH:

OP_HASH160
OP_PUSHBYTES_20
748284390f9e263a4b766a75d0633c50426eb875
OP_EQUAL

a914748284390f9e263a4b766a75d0633c50426eb87587

Transaction: 450c309b70fb3f71b63b10ce60af17499bd21b1db39aa47b19bf22166ee67144 (Output 1)

This particular Script Hash is the HASH160 of a P2MS locking script, but we only find that out when the Redeem Script is revealed in the ScriptSig…

ScriptSig

The unlocking script for a P2SH consists of two parts:

The unlocking code required to unlock the upcoming Redeem Script.
A data push of the actual Redeem Script.

OP_0
OP_PUSHBYTES_71
3044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401
OP_PUSHBYTES_71
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Transaction: 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30 (Input 11)

So in other words, the ScriptSig contains the complete unlocking script and locking script.

In the example above, the Redeem Script is the data push of a P2MS locking script. The signature that comes before it is what's required to unlock it.

You can inspect the Redeem Script to find out that it is indeed a P2MS by decoding it from hex:

Script

Execution

P2SH is a special form of locking script and is executed slightly differently to "normal" scripts.

A P2SH script is executed in two steps:

Step 1: Standard Script Execution — The Redeem Script is hashed and checked to se if it equals the Script Hash.
Step 2: Redeem Script Execution (special part) — The Redeem Script is deserialized and ran as if it were the locking script.

An animation showing the execution of a full P2SH script.

The stack containing the ScriptSig gets copied so that the P2SH can be executed in two steps.

Step 1: Standard Script Execution

The Redeem Script from the ScriptSig gets hashed to make sure it matches the Script Hash in the ScriptPubKey:

A diagram showing the first step of execution for a P2SH.

This is perfectly normal script execution, and this is where the script execution would normally end.

However, because P2SH is a special form of locking script, there is an additional step…

Step 2: Redeem Script Execution (special part)

The Redeem Script (which is a data push) is deserialized into its component parts (of opcodes and data):

An animation showing the Redeem Script being deserialized for second step of the script execution.

So you could think of the Redeem Script as becoming the new locking script.

Anyway, after the Redeem Script has been deserialized, the whole script is run like any standard script.

Seeing as the Redeem Script in the example above contains a P2MS, it executes like a standard P2MS script. But of course, this part could be executed differently depending on the type of Redeem Script you use.

Redeem Script

The custom script

The Redeem Script is a data push of the hex-encoding of a custom locking script. This is the last item inside the ScriptSig of a P2SH.

Here's an example ScriptSig:

OP_0
OP_PUSHBYTES_71
3044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401
OP_PUSHBYTES_71
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Transaction: 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30 (Input 11)

If you decode the last item, you'll see that it corresponds to the following script (which is a typical P2MS):

OP_1
OP_PUSHBYTES_33
022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e
OP_PUSHBYTES_33
03a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c0
OP_2
OP_CHECKMULTISIG

5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Script

You can use just about any custom locking script you want as the Redeem Script. And as of Bitcoin 0.10.0 you are no longer limited to using standard scripts only:

The IsStandard() rules have been almost completely removed for P2SH redemption scripts, allowing applications to make use of any valid script type, such as “n-of-m OR y”, hash-locked oracle addresses, etc. While the Bitcoin protocol has always supported these types of script, actually using them on mainnet has been previously inconvenient as standard Bitcoin Core nodes wouldn’t relay them to miners, nor would most miners include them in blocks they mined.

Bitcoin 0.10.0 Release Notes

So if you want some fun with the various OP_CODES, the Redeem Script of a P2SH is where you can have it.

Whilst a Redeem Script contains opcodes and data, it's actually the hex-encoding of a script, and gets pushed on to the stack (just like a public key does in a P2PKH).

The maximum size of a Redeem Script is 520 bytes. Anything larger is considered non-standard and will not be relayed by nodes. In practical terms this means you can use it for a P2MS-style locking script with up to 15 public keys.

Make sure that your non-standard script will end up leaving a single OP_1 left on the stack at the end of execution.

I created a script once that left OP_1 OP_1 OP_1 on the stack, and even thought the top element was OP_1, I got an "Extra items left on stack after execution" error and the transaction wouldn't be relayed.

Script Hash

The hash of the custom script

The Script Hash is the HASH160 of the Redeem Script. This is placed inside the ScriptPubKey of a P2SH.

For example, you can see the Redeem Script is the last data push in this ScriptSig:

OP_0
OP_PUSHBYTES_71
3044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401
OP_PUSHBYTES_71
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Transaction: 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30 (Input 11)

If you HASH160 this Redeem Script, you'll see that it is equal to the Script Hash found in the original ScriptPubKey:

OP_HASH160
OP_PUSHBYTES_20
748284390f9e263a4b766a75d0633c50426eb875
OP_EQUAL

a914748284390f9e263a4b766a75d0633c50426eb87587

Transaction: 450c309b70fb3f71b63b10ce60af17499bd21b1db39aa47b19bf22166ee67144 (Output 1)

Script

HASH160

Examples

Where can you find P2SH scripts?

Here are some examples of P2SH being used in transactions.

I've included the decoded Redeem Script from each ScriptSig, as that's the most interesting part, because that's where the "custom" locking script is located.

Remember that the Redeem Script is the last data push inside the ScriptSig and appears as a bunch of hex bytes, so to inspect them you'll need to decode them:

Script

Example 1

This was the first transaction to use P2SH (and to also be spent later on).

ScriptPubKey: a0f1aaa2fb4582c89e0511df0374a5a2833bf95f7314f4a51b55b7b71e90ce0f (output 1)
ScriptSig: 4d8eabfc8e6c266fb0ccd815d37dd69246da634df0effd5a5c922e4ec37880f6 (input 2)

The Redeem Script is a 1-of-2 multisig locking script:

OP_1
OP_PUSHBYTES_33
022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e
OP_PUSHBYTES_33
03a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c0
OP_2
OP_CHECKMULTISIG

5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Example 2

ScriptPubKey: 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8 (output 0)
ScriptSig: 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45 (input 0)

The Redeem Script is a 1-of-1 multisig locking script:

OP_1
OP_PUSHBYTES_65
042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf
OP_1
OP_CHECKMULTISIG

5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

Example 3

ScriptPubKey: 450c309b70fb3f71b63b10ce60af17499bd21b1db39aa47b19bf22166ee67144 (output 1)
ScriptSig: 30c239f3ae062c5f1151476005fd0057adfa6922de1b38d0f11eb657a8157b30 (input 11)

The Redeem Script is a 1-of-2 multisig locking script. It's using the same lock as the very first P2SH example above:

OP_1
OP_PUSHBYTES_33
022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e
OP_PUSHBYTES_33
03a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c0
OP_2
OP_CHECKMULTISIG

5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae

Example 4

ScriptPubKey: d3adb18d5e118bb856fbea4b1af936602454b44a98fc6c823aedc858b491fc13 (output 0)
ScriptSig: cc11ca9e9dc188663c41eb23b15370f68eded56b7ec54dd5bc4f2d2ae93addb2 (input 0)

The Redeem Script is a 2-of-3 multisig locking script:

OP_2
OP_PUSHBYTES_65
04f3d35132084eb1b99b6506178c20adb42d26296012e452e392689bdb6553db33ba24b900000892805de1646821c7b0fb50b3d879c26e2b493b7041e6215356a0
OP_PUSHBYTES_65
04ab4ecc9e8ea2da0562af25bcaede00c4d5a00db60edc17672376decf0a35a34fdc9f1ffad1fb74fd7b1b198b9231c25df88e0769bec49975649b4b3f40adafb0
OP_PUSHBYTES_65
04f7149f270717c00f6cc09b9ce3c22791c4aab1af40a5107aacca85b6f644cc0d84459e308f998d801b8d9d355f8ec33b0e41866841e2870754cf667a9821703d
OP_3
OP_CHECKMULTISIG

524104f3d35132084eb1b99b6506178c20adb42d26296012e452e392689bdb6553db33ba24b900000892805de1646821c7b0fb50b3d879c26e2b493b7041e6215356a04104ab4ecc9e8ea2da0562af25bcaede00c4d5a00db60edc17672376decf0a35a34fdc9f1ffad1fb74fd7b1b198b9231c25df88e0769bec49975649b4b3f40adafb04104f7149f270717c00f6cc09b9ce3c22791c4aab1af40a5107aacca85b6f644cc0d84459e308f998d801b8d9d355f8ec33b0e41866841e2870754cf667a9821703d53ae

Example 5

ScriptPubKey: 7d46745463a28049cb93d2c964320912d9c296c1038cb24cc3716255c397a87f (output 1)
ScriptSig: 09afa3b1393f99bb01aa754dd4b89293fd8d6c9741488b537d14f7f81de1450e (input 0)

The Redeem Script is a non-standard locking script containing a mathematical puzzle:

OP_3DUP
OP_ADD
OP_9
OP_EQUALVERIFY
OP_ADD
OP_7
OP_EQUALVERIFY
OP_ADD
OP_8
OP_EQUALVERIFY
OP_1

6f93598893578893588851

Example 6

ScriptPubKey: 2c6c3a1319c3e42b4801dab62e3d3d59c51c3535b8dad20e9580650f114c7026 (output 0)
ScriptSig: 8d31992805518fd62daa3bdd2a5c4fd2cd3054c9b3dca1d78055e9528cff6adc (input 4)

The Redeem Script is a non-standard locking script containing Peter Todd's hash-collision challenge where you had to find two different pieces of data that produce the same SHA-1 result:

OP_2DUP
OP_EQUAL
OP_NOT
OP_VERIFY
OP_SHA1
OP_SWAP
OP_SHA1
OP_EQUAL

6e879169a77ca787

As you can see, P2SH is most commonly used for multisig locks (P2MS), but it's occasionally used for more exotic custom locking scripts for fun.

Address

How do you create an address for a P2SH script?

The P2SH locking script pattern has been assigned its own address.

The address for a P2SH locking script is the Base58Check encoding of the Script Hash with a 1-byte prefix of 05 (mainnet) or c4 (testnet).

A P2SH address always starts with a 3 (mainnet) or 2 (testnet).

When a wallet encounters this type of address, it will decode it from base58 to extract the Script Hash, then use that to construct a P2SH locking script to be placed on the output of the transaction.

Diagram showing how to decode an address to a P2SH script.

Benefits

Why do we use P2SH?

The main benefit of P2SH is that it makes it easier to share complex locking scripts with other people.

Before P2SH, if you wanted a complex locking script placed on your bitcoins (e.g. P2MS), you would have to give the person "sending" you those bitcoins the entire locking script:

A diagram showing a full locking script being shared with someone.

But with P2SH, instead of giving someone an entire locking script, you can essentially just give them a hash of your script instead:

A diagram showing the hash of a script being shared with someone instead of the full locking script.

Furthermore, this script hash can be converted to an address format to make it even easier to share:

A diagram showing an address (formed from the hash of a script) being shared with someone.

As a result, the sender is no longer be burdened with the size (or the technical details) of our locking script, and they can simply "send" the bitcoins to a standardized address instead.

Other benefits

There are also a few other benefits to using P2SH:

1. Cheaper transaction costs for the sender

If you want a custom locking script on your bitcoins, the person sending you the bitcoins has to put this script into the transaction they create:

A diagram showing a P2MS being used as a locking script on an output and its size in raw transaction data.

The problem here is that this larger locking script increases the size of the transaction data, so the sender will have to pay more in transaction fees to accommodate your script.

However, with P2SH they can create a lock using the hash of your script instead, which is much smaller than the full script:

A diagram showing a P2SH being used as a locking script on an output and its size in raw transaction data.

As a result, the burden of large locking scripts is no longer on the sender and is moved to the receiver instead. This helps to avoid a situation where a sender would be complacent about "sending" bitcoins to a locking script that isn't one of the simplest and cheapest (e.g. P2PKH).

2. P2SH has a little more privacy

Seeing as a P2SH locking script just contains the hash of another locking script, it's impossible to know what kind of locking script that hash came from by just looking at it:

A diagram showing the hash of a script placed inside the lock of a transaction and being unable to determine the original script.

As a result, nobody would know if an output "belongs" to one person's public key, or if it belongs to multiple people.

That's until someone spends it and reveals the Redeem Script, of course.

3. A smaller UTXO set

To make the bitcoin program itself run as fast as possible, all of the unspent outputs from transactions (UTXOs) are stored in RAM on your computer.

A diagram showing the UTXOs being stored in RAM.

RAM is smaller than your hard drive, but it gives you much faster access to data.

These UTXOs also store the locking scripts for each output, so by using smaller P2SH scripts instead of larger P2MS scripts, you save on the amount of RAM needed to hold the UTXO set.

This is useful, because keeping as much of the UTXO set in RAM makes nodes much faster at validating transactions.

FAQ

Doesn't P2SH take up more space in the blockchain overall?

Yes, it does.

For example, a complete 2-of-3 multisig script using the simple P2MS pattern takes up 253 bytes in the blockchain:

A diagram showing the size of a complete P2MS script.

On the other hand, a complete 2-of-3 multisig script using P2SH takes up 278 bytes in the blockchain:

A diagram showing the size of a complete P2SH script.

So the extra step of locking bitcoins to the hash of a script adds an extra 25 bytes to the overall script.

However, there isn't really any alternative for being able to create addresses for custom locking scripts, so the extra 25 bytes for this convenience is a reasonable price to pay.

Resources

P2SH bytes structure