<p>Before the adoption of <a href="https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki" rel="nofollow noreferrer">BIP16: Pay to Script Hash</a>, multisig was possible, but only in the form of bare outputs. The multisig would be directly defined in the <code>ScriptPubKey</code> (the output script). This had three disadvantages. There was no address standard for encoding these flexible constructions, the resulting big output script had to be paid for by the sender but was for the benefit of the receiver, and the big output script would also cause the UTXO would be much larger than other UTXOs, which then would need to be stored by all full nodes until it got spent.</p>
<p>BIP16 introduced a level of indirection. Instead of directly encoding the condition script in the <code>ScriptPubKey</code>, the <code>ScriptPubKey</code> contains a P2SH Program which commits to one specific Redeem Script via a hash of it. The <code>ScriptSig</code> (the input script) provides the actual spending conditions in the form of the Redeem Script (matching the hash commitment in the output), and the script arguments to satisfy the Redeem Script.</p>
<p>The Redeem Script can contain any valid Script expression, including one that requires only the signature of a single key to spend. This construction would be less blockspace efficient than using a single-sig output type in the first place, though.</p>
<p>Since the P2SH Program always had a fixed length, it was easy to make an address standard for it, and the cost of the outputs was no longer as burdensome.</p>
<p><a href="https://i.sstatic.net/Z4QPz.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Z4QPz.png" alt="enter image description here" /></a></p>
<p>About 35% of all transaction outputs today are P2SH outputs with the majority encoding wrapped segwit outputs. We have more blockspace efficient output types now. Using one of P2WPKH, P2WSH, and P2TR it would be able to achieve any equivalent condition script using less blockspace.</p>

CC BY-SA 4.0
2022-06-30T12:07:17.097Z
Another disadvantage was that the sender had to bear (a significant) part of the cost for a decision made by the recipient (to receive coins on a multisig).
Antoine Poinsot
CC BY-SA 4.0
2022-06-30T12:11:00.717Z
So who creates the scriptpubkey (unlocking script) and scriptsig (unlocking script). Is it the people who are receiving the Bitcoins or is the people who want to transact the Bitcoins?
Jamo
CC BY-SA 4.0
2022-06-30T12:15:02.527Z
@AntoinePoinsot: Great point, added
Murch
CC BY-SA 4.0
2022-06-30T12:28:35.873Z
@Jamo: The receiver always decides how they'd like to get paid. They then communicate to the sender instructions how to pay them, usually in form of an address. The sender builds the transaction, so while the receiver defines the content of the `ScriptPubkey`, the sender creates it.
Murch
CC BY-SA 4.0
2022-06-30T12:03:31.310Z
2022-06-30T21:20:39.240Z
2022-06-30T21:20:39.240Z
Murch
<p>I have a few questions relating to Bitcoin Signatures And P2SH:</p>
<p>Why is P2SH used as opposed to other forms? Is it still prevalent today - has SegWit made it redundant or less useful, if not, what is the most used signature format?</p>
<p>And mainly:</p>
<p><strong>Can the P2SH redeem script consist of a single public key (hence only one person is creating the redeem script). What even is the redeem script?</strong></p>

<script><segregated-witness><signature><p2sh>
Can The Redeem Script Consist Of Only 1 Public Key In P2SH Transactions:
Jamo
# Can The Redeem Script Consist Of Only 1 Public Key In P2SH Transactions:

(Asked by: username_0 on 2022-06-30)

I have a few questions relating to Bitcoin Signatures And P2SH:

Why is P2SH used as opposed to other forms? Is it still prevalent today - has SegWit made it redundant or less useful, if not, what is the most used signature format?

And mainly:

**Can the P2SH redeem script consist of a single public key (hence only one person is creating the redeem script). What even is the redeem script?**

**Tags:** script, segregated-witness, signature, p2sh


---

## 1 answers

### Answer by username_1 on 2022-06-30. Score: 5 | Accepted answer

Before the adoption of [BIP16: Pay to Script Hash](https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki), multisig was possible, but only in the form of bare outputs. The multisig would be directly defined in the `ScriptPubKey` (the output script). This had three disadvantages. There was no address standard for encoding these flexible constructions, the resulting big output script had to be paid for by the sender but was for the benefit of the receiver, and the big output script would also cause the UTXO would be much larger than other UTXOs, which then would need to be stored by all full nodes until it got spent.

BIP16 introduced a level of indirection. Instead of directly encoding the condition script in the `ScriptPubKey`, the `ScriptPubKey` contains a P2SH Program which commits to one specific Redeem Script via a hash of it. The `ScriptSig` (the input script) provides the actual spending conditions in the form of the Redeem Script (matching the hash commitment in the output), and the script arguments to satisfy the Redeem Script.

The Redeem Script can contain any valid Script expression, including one that requires only the signature of a single key to spend. This construction would be less blockspace efficient than using a single-sig output type in the first place, though.

Since the P2SH Program always had a fixed length, it was easy to make an address standard for it, and the cost of the outputs was no longer as burdensome.

[![enter image description here](https://i.sstatic.net/Z4QPz.png)](https://i.sstatic.net/Z4QPz.png)

About 35% of all transaction outputs today are P2SH outputs with the majority encoding wrapped segwit outputs. We have more blockspace efficient output types now. Using one of P2WPKH, P2WSH, and P2TR it would be able to achieve any equivalent condition script using less blockspace.

> **Comments:**
> **username_2**: Another disadvantage was that the sender had to bear (a significant) part of the cost for a decision made by the recipient (to receive coins on a multisig).  
> **username_0**: So who creates the scriptpubkey (unlocking script) and scriptsig (unlocking script). Is it the people who are receiving the Bitcoins or is the people who want to transact the Bitcoins?  
> **username_1**: @username_2: Great point, added  
> **username_1**: @username_0: The receiver always decides how they'd like to get paid. They then communicate to the sender instructions how to pay them, usually in form of an address. The sender builds the transaction, so while the receiver defines the content of the `ScriptPubkey`, the sender creates it.  

---

