P2SH Pay-to-Script-Hash Script in Bitcoin
In this article, we introduce ourselves to the pay-to-script-hash script in Bitcoin that allows users to lock bitcoins to the hash of a script, after which the recipient needs to provide the original script to be able to spend the sent bitcoins.
Table of contents.
- Introduction.
- How a P2SH Works.
- Pros and Cons of P2SH.
- Summary.
- References.
Introduction
In the previous articles, we learned about the Bitcoin script programming language. We also look at the two major categories of bitcoin transaction scripts namely the locking script that specifies a condition to be met before funds can be spent on a transaction output and unlocking scripts which are used to satisfy the condition specified by the locking script.
In addition to this, we learn about a commonly used transaction script referred to as the *Pay-To-Public-Key-Hash(P2PKH).
In this article, we learn about another transaction locking script referred to as the Pay-To-Script-Hash(P2SH). For bitcoins to be spent, this condition specified in this script must be satisfied by the recipient. A transaction that uses this script has inputs locked with this script.
Let us consider the case of two transacting parties A and B. A wants to send some bitcoins to B. For this A embeds the hash of the script that is required to spend the bitcoins to be sent. The script has conditions that B has to meet before he/she can spend any amount. When the transaction is sent to B, B reconstructs the hash of the script that was used by A and signs the transaction with private keys as required by the script.
The following image demonstrates a simple P2SH Bitcoin transaction;
Unlike P2PKH, P2SH provides flexibility in that users can construct an arbitrary number of scripts, also in our example, A only includes the hash of the script and not the script itself, this ensures privacy for A. P2SH is also backward compatible with other transaction types such as SegWit.
P2SH was introduced in BIP-16 back in January 2012. The motivation behind its introduction was to move the responsibility of supplying the conditions to redeem a transaction from the sender to the recipient(redeemer) of the funds. This allowed the sender to fund arbitrary transactions(including complex ones) using a fixed-length 20-byte hash that could be easily copied and pasted.
How a P2SH Works.
To get started, the transaction is passed through a cryptographic hashing function that produces a fixed-length string which is the transaction hash.
Unlike P2PKH transactions where the input is the recipient's public key, P2SH has more complex inputs. Additional constraints such as multi signatures may be included within the transaction. These are programmed using the script language.
The script is then hashed and the hash is used to lock the funds in a Pay-To-Script-hash transaction as shown below;
Output (scriptPubKey)
--------------------------------
OP_HASH160 <scripthash> OP_EQUAL
Now, for a recipient to be able to spend the sent funds locked in the transaction, he/she must reverse the hash of the script to generate the original script used to lock the funds. The generated script is referred to as a redeem script. It is used to verify that the corresponding script, the script hash, and the signature script produced by the recipient are correct. If valid the recipient can spend the funds.
To following is what unlocking a P2SH looks like;
Input (scriptSig)
-------------------------------------------
scriptSig scriptPubKey (as a data push)
---------------------------- --------------
OP_0 <signature> <signature> <redeemscript>
Here we have both the locking and unlocking scripts both contained inside the unlocking script(scriptSig).
During execution, the <redeemscript> is first hashed and compared with the <scripthash>. If they match, the redeem script is deserialized and we have the following;
Input (scriptSig)
-------------------------------------------
scriptSig scriptPubKey
---------------------------- --------------
OP_0 <signature> <signature> OP_2 <pubkey> <pubkey> <pubkey> OP_3 OP_CHECKMULTISIG
Above we have a multi-signature script with multiple public keys. In this case, it is wrapped in a P2SH because it is much cheaper for the sender in terms of fees.
P2SH is executed in two parts, standard execution and redeem script execution.
- During standard execution, the redeem script is hashed and then compared to the script hash in the locking script(scriptPubKey). Usually, script execution stops here, BIP-16 included an additional step described below.
- During redeem script execution, the redeem script is deserialized and executed like a standard locking script.
The steps can be summarized as follows;
-
The recipient generates a set of spending conditions - the redeem script.
-
The recipient generates a bitcoin address by hashing the redeem script and encoding this in the address format.
-
The sender sends the funds to the address with funds locked according to the specified conditions in 1.
-
For the recipient to spend the sent bitcoins, he/she provides the valid redeem script which is a hash that matches the address. The redeem script is then executed as a locking script.
Pros and Cons of P2SH.
P2SH was a patch added to Bitcoin back in 2012 to improve the way transactions were validated. This improvement brought with it many pros as well as cons. Let us look at some of these.
Pros
- We discussed multi-sig in the previous article and saw their benefits such as security and decentralized control of a wallet's funds, P2SH supports multisig shared wallets.
- P2SH also supports SegWit and Non-SegWit. A Nested SegWit is a bitcoin wallet created using private keys that is in P2SH format.
- Compared to other transaction scripts such as P2MS script, these are much smaller, this, in turn, translates to less transaction data which means a faster network and smaller transaction fees.
- Bitcoin senders don't have to write complex scripts since P2SH transactions are only executed by sending a standard address format that begins with '3'.
- Hashing ensures the security and immutability of transactions and transaction data.
- Miners also don't require a lot of computational resources to process P2SH transactions, therefore transactions are validated faster and fees are cheaper.
- Transaction costs of a long script are transferred to the recipient in that, he/she has to include the long script in order to spend the sent coins.
- In the case of a long script, its storage is postponed to the future when it will be spent.
- Storing a long script is shifted from the output from the UTXO set to input stored in the blockchain.
Cons
- Compared to Pay-To-MultiSig(P2MS), 2-of-3 mutlisignatured scripts using P2SH scripts are much larger, this means they take more space and use more network bandwidth.
- Its adoption is limited since P2SH was developed to support multi-signature transactions, most blockchain users just use a single signature to sign transactions.
Summary
P2SH locking scripts store the hash of the redeem script that holds no clues as to the content of the redeem script itself.
Even if the redeem script is invalid, the transaction remains valid, meaning we will still have the bitcoins but won't be able to spend them.