Pay To Script Hash
Greg Walker- Download PDF
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_HASH160OP_PUSHBYTES_20748284390f9e263a4b766a75d0633c50426eb875OP_EQUAL a914748284390f9e263a4b766a75d0633c50426eb87587Transaction: 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_0OP_PUSHBYTES_713044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401OP_PUSHBYTES_715121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeTransaction: 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. And 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 that 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.
The stack containing the ScriptPubKey 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:
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 in to its component parts (of opcodes and data):
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 execute 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_0OP_PUSHBYTES_713044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401OP_PUSHBYTES_715121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeTransaction: 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
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeScript
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.
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_0OP_PUSHBYTES_713044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401OP_PUSHBYTES_715121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
00473044022100d0ed946330182916da16a6149cd313a4b1a7b41591ee52fb3e79d64e36139d66021f6ccf173040ef24cb45c4db3e9c771c938a1ba2cf8d2404416f70886e360af401475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeTransaction: 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_HASH160OP_PUSHBYTES_20748284390f9e263a4b766a75d0633c50426eb875OP_EQUAL a914748284390f9e263a4b766a75d0633c50426eb87587Transaction: 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
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeExample 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
5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51aeExample 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
5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052aeExample 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
524104f3d35132084eb1b99b6506178c20adb42d26296012e452e392689bdb6553db33ba24b900000892805de1646821c7b0fb50b3d879c26e2b493b7041e6215356a04104ab4ecc9e8ea2da0562af25bcaede00c4d5a00db60edc17672376decf0a35a34fdc9f1ffad1fb74fd7b1b198b9231c25df88e0769bec49975649b4b3f40adafb04104f7149f270717c00f6cc09b9ce3c22791c4aab1af40a5107aacca85b6f644cc0d84459e308f998d801b8d9d355f8ec33b0e41866841e2870754cf667a9821703d53aeExample 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
6f93598893578893588851Example 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
6e879169a77ca787As 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 and 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, they 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.
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:
But with P2SH, instead of giving someone an entire locking script, you can essentially just give them a hash of your script instead:
Furthermore, this script hash can be converted to an address format to make it even easier to share:
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 in to the transaction they create:
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:
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:
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.
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:
On the other hand, a complete 2-of-3 multisig script using P2SH takes up 278 bytes in the blockchain:
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.
