P2SH (Pay To Script Hash)
  • Hash256
  • Hash160
  • Reverse Bytes
Youtube

P2SH Pay To Script Hash

P2SH was introduced as a standard script in April 2012. It allows you to lock bitcoins to the hash of a script, and you then provide that original script when you come unlock those bitcoins.

It basically allows you to create your own custom "redeem scripts", but still be able to share them easily with other people.

BIP 16: Pay to Script Hash (03 January 2012)

How does P2SH work?

The locking script contains the hash of a your custom locking script (the "script hash"), surrounded by the HASH160 and EQUAL opcodes:

scriptPubKey a914748284390f9e263a4b766a75d0633c50426eb87587
OP_HASH160 748284390f9e263a4b766a75d0633c50426eb875 OP_EQUAL
P2SH
hex | opcodes inline | stack

The unlocking script then contains your original custom locking script (the "redeem script"), preceeded by the data/opcodes needed to unlock it:

scriptSig 00493046022100a07b2821f96658c938fa9c68950af0e69f3b2ce5f8258b3a6ad254d4bc73e11e022100e82fab8df3f7e7a28e91b3609f91e8ebf663af3a4dc2fd2abd954301a5da67e701475121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
OP_0 3046022100a07b2821f96658c938fa9c68950af0e69f3b2ce5f8258b3a6ad254d4bc73e11e022100e82fab8df3f7e7a28e91b3609f91e8ebf663af3a4dc2fd2abd954301a5da67e701 5121022afc20bf379bc96a2f4e9e63ffceb8652b2b6a097f63fbee6ecec2a49a48010e2103a767c7221e9f15f870f1ad9311f5ab937d79fcaeee15bb2c722bca515581b4c052ae
hex | opcodes inline | stack

So in the unlocking script above, the redeem script is a P2MS locking script itself, and the preceeding signature is what's needed to unlock it.

Execution.

Special Form: The P2SH locking script pattern is recognized as a "special" form, so it gets executed slightly differently to "normal" scripts.

A P2SH script is executed in two parts:

  1. Standard Execution - The redeem script is hashed, and is then checked that it is equal the script hash in the locking script.
  2. Redeem Script Execution - This is the special part. The redeem script is deserialized and ran as if it were a locking script.

1. Standard Execution

First of all, the entire script is executed as normal:

The redeem script gets hashed to make sure it matches the hash in the scriptPubKey.

The redeem script gets hashed to make sure it matches the hash in the scriptPubKey.

Normally, this is where the script execution would end. However, because of the changes made to bitcoin thanks to BIP 16, we move on to the second step of P2SH script execution...

2. Redeem Script Execution

The second part of the script execution is only concerned with the original scriptSig. The redeem script (which is a data push) is deserialized in to its component parts (of opcodes and data).

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, here's how the whole script would run:

During execution, the stack containing the scriptPubKey actually gets copied before running the first step.

During execution, the stack containing the scriptPubKey actually gets copied before running the first step.

Why do we have P2SH?

Because it makes it easier to share complex locking scripts with other people.

Before P2SH, if you wanted a complex locking script (e.g. P2MS) placed on your bitcoins, 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:

You provide your original script when you unlock the bitcoins later on.

You provide your original script when you unlock the bitcoins later on.

As a result, the sender is no longer burdened with the size (or the details) of your locking script.

What are the benefits of P2SH?

There are a few benefits that come with 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:

Larger locking scripts increase the size of the transaction data, so the sender will have to pay more in transaction fees to accommodate your script.

Larger locking scripts increase 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 therefore 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. We can use addresses for P2SH locking scripts.

Due to the fact that every P2SH locking script has a uniform structure (thanks to the fixed-size hash, we can easily have a standard address format for it (similar to the P2PKH address format).

P2SH addresses start with a 3 (thanks to the 0x05 prefix before converting to base58).

P2SH addresses start with a 3 (thanks to the 0x05 prefix before converting to base58).

So instead of having to pass the actual P2SH locking script around, we can shorten it (again) and make it easier to share by converting it to an address.

Remember that addresses include a checksum and use base58 characters, so they're better for sharing than the raw script hash.

Remember that addresses include a checksum and use base58 characters, so they're better for sharing than the raw script hash.

3. 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:

The script hash could be the hash of any kind of script.

The script hash could be the hash of any kind of 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.

4. 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 gives you fast access to data, but holds less than your hard drive.

RAM gives you fast access to data, but holds less than your hard drive.

These UTXOs also contain the locking scripts (scriptPubKeys), so by using smaller P2SH scripts instead of larger P2MS scripts, you save on the amount of RAM needed to hold the UTXO set.

If you couldn't fit the entire UTXO set in RAM, nodes would become slower at validating transactions.

Where can you find P2SH scripts?

Look for the outputs with a 3address. You can tell what kind of lock it is (e.g. multisig) by looking at the contents of the redeem script in the scriptSig.

P2SH is used whenever someone wants to put a multisig lock on their bitcoins. Here are some examples of P2SH being used for multisig:

P2SH can also be used for custom (non-standard) redeem scripts. Here are some interesting ones:

What kind of scripts can you put in the redeem script?

You can put just about any custom locking script you want as the redeem script.

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 OPCODES, the redeem script of a P2SH is where you can have it.

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

Yes, you're right.

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.

Not to mention the other benefits of P2SH.

By Greg Walker,

Last Updated: 24 May 2019
  • 24 May 2019: Added Hashover comment system (basic functionality to test it out)
  • 31 Jan 2019: script page checks and edits
  • 30 Jan 2019: added p2sh_example tx code
  • 29 Jan 2019: Updated title images for script pages. Also added simple breadcrumb for these pages too.
  • 26 Jan 2019: page edits
  • 25 Jan 2019: p2sh page now has redeem script tooltip
  • 25 Jan 2019: script examples now have hex switches and show the tooltips thanks to using the output.js file in browser/transaction/output
  • 23 Jan 2019: First draft of P2PK, P2PKH, P2MS, and P2SH pages.

Hey there, it's Greg.

I'll let you know about cool website updates, or if something seriously interesting happens in bitcoin.


Don't worry, it doesn't happen very often.