<p>The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.</p>

<p>So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 out of a set of 5 keys to spend my coins. So, the <code>scriptPubKey</code> that I would like everyone to use when they send coins to me is:</p>

<pre><code>OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG
</code></pre>

<p>But each pubkey is 33 bytes and so this makes a script that is ~170 bytes, which is a bit much to encode in a QR code. And it is definitely is too much data for a human to process. </p>

<p>But if I use P2SH, the <code>scriptPubKey</code> is just 23 bytes and the sender doesn't have to worry about what exactly the redeem condition I am setting on my coins is. P2SH works like this. I take the script that I want to be my <code>scriptPubKey</code> and I serialize it (I'll use {} to denote serialization):</p>

<pre><code>redeemScript = {OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG}
redeemScript_hash = hash160(sha256(redeemScript))
</code></pre>

<p>And then the <code>scriptPubKey</code> that the sender actually uses is:</p>

<pre><code>OP_HASH160 {redeemScript_hash} OP_EQUAL
</code></pre>

<p>Which is just 23 bytes in total. The nice thing is that it provides a layer of abstraction. The person who is sending me coins doesn't need to know how I am keeping my coins secure. All they see is a hash of a <code>redeemScript</code>, but they don't know what conditions that <code>redeemScript</code> actually puts on redeeming the coins.</p>

<p>Basically, P2SH itself is not inherently more secure because the redeem script can be anything. But what it does is enable coin-receivers to easily communicate how coin-senders should send them coins, while letting the coin-receivers dictate the conditions of how/when those coins can be spent.</p>

CC BY-SA 3.0
2015-03-31T22:36:37.957Z
2015-03-31T22:59:57.503Z
2015-03-31T22:59:57.503Z
morsecoder
<p>To steal a P2PKH output you would have to find the private key of the public key that generated the hash used in the tx. This is impossible to do in a feasible timespan, therefore making the tx secure. What incentivized the use of P2SH? I'm particularly asking in the light of <a href="https://bitcoin.org/en/developer-guide#p2sh-scripts" rel="nofollow">this paragraph</a> of the Bitcoin developer guide:</p>

<blockquote>
  <p>Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. Receivers do care about the conditions imposed on the satoshis by the pubkey script and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and more difficult to secure than P2PKH pubkey hashes.</p>
</blockquote>

<p>I have been unable to find an example of a "reedem script", could you give one?</p>

CC BY-SA 3.0
2015-03-31T20:37:37.230Z
I don't think P2SH was brought about by security threats at all. I think it came about because people wanted an easy way to use multisig.
Nick ODell
CC BY-SA 3.0
2015-03-31T21:26:50.393Z
Acording to [Bitcoin's documentation](https://bitcoin.org/en/developer-guide#p2pkh-script-validation): "Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. " impliying that long-term security in the P2PKH transaction model is compromised.
randomname453
CC BY-SA 3.0
2015-04-01T08:40:17.207Z
@randomname453 If it didn't say "security" I'd argue it's referring to data storage in the Blockchain using multisig
Wizard Of Ozzie
CC BY-SA 3.0
2015-04-01T11:02:24.197Z
I wrote the paragraph quoted, and it was not at all my intention to imply that P2PKH is compromised.  (P2PKH is vulnerable to exactly the same systematic threats as P2SH, so neither is more secure than the other.)  The security I'm referring to is the security provided by the conditions of the pubkey script, which can be made more or less secure by changing the conditions---for example, a user with two separate devices can require both devices sign a transaction using 2-of-2 multisig, something than single sigs can't do.  Stephen's answer below, especially his final paragraph, is what I'd say.
David A. Harding
CC BY-SA 3.0
2015-04-01T13:29:27.377Z
Note: I've updated the text in the Bitcoin.org developer guide to no longer mention anything about security.  I'm sorry for any confusion.  Here's the patch: https://github.com/bitcoin/bitcoin.org/commit/2c1615e75b89cf78df16d9213b3fd6da5f89cc1b
David A. Harding
<p2sh>
Which security threats in P2PKH lead to the use of P2SH?
randomname453
# Which security threats in P2PKH lead to the use of P2SH?

(Asked by: username_0 on 2015-03-31)

To steal a P2PKH output you would have to find the private key of the public key that generated the hash used in the tx. This is impossible to do in a feasible timespan, therefore making the tx secure. What incentivized the use of P2SH? I'm particularly asking in the light of [this paragraph](https://bitcoin.org/en/developer-guide#p2sh-scripts) of the Bitcoin developer guide:

> Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. Receivers do care about the conditions imposed on the satoshis by the pubkey script and, if they want, they can ask spenders to use a particular pubkey script. Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and more difficult to secure than P2PKH pubkey hashes.

I have been unable to find an example of a "reedem script", could you give one?

**Tags:** p2sh

> **Comments:**
> **username_1**: I don't think P2SH was brought about by security threats at all. I think it came about because people wanted an easy way to use multisig.  
> **username_0**: Acording to [Bitcoin's documentation](https://bitcoin.org/en/developer-guide#p2pkh-script-validation): "Pubkey scripts are created by spenders who have little interest in the long-term security or usefulness of the particular satoshis they’re currently spending. " impliying that long-term security in the P2PKH transaction model is compromised.  
> **username_2**: @username_0 If it didn't say "security" I'd argue it's referring to data storage in the Blockchain using multisig  
> **username_3**: I wrote the paragraph quoted, and it was not at all my intention to imply that P2PKH is compromised.  (P2PKH is vulnerable to exactly the same systematic threats as P2SH, so neither is more secure than the other.)  The security I'm referring to is the security provided by the conditions of the pubkey script, which can be made more or less secure by changing the conditions---for example, a user with two separate devices can require both devices sign a transaction using 2-of-2 multisig, something than single sigs can't do.  Stephen's answer below, especially his final paragraph, is what I'd say.  
> **username_3**: Note: I've updated the text in the Bitcoin.org developer guide to no longer mention anything about security.  I'm sorry for any confusion.  Here's the patch: https://github.com/bitcoin/bitcoin.org/commit/2c1615e75b89cf78df16d9213b3fd6da5f89cc1b  

---

## 1 answers

### Answer by username_4 on 2015-03-31. Score: 6 | Accepted answer

The only security concern of P2PKH is that it only requires 1 key to spend coins paid to it. P2SH just lets you be even more secure by easily putting more conditions on the redemption of your coins, like requiring more than 1 key to spend.

So, let's say I'm a person that wants to keep my bitcoins really safe, and the way I want to do that is by requiring 3 out of a set of 5 keys to spend my coins. So, the `scriptPubKey` that I would like everyone to use when they send coins to me is:

```
OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG

```

But each pubkey is 33 bytes and so this makes a script that is ~170 bytes, which is a bit much to encode in a QR code. And it is definitely is too much data for a human to process.

But if I use P2SH, the `scriptPubKey` is just 23 bytes and the sender doesn't have to worry about what exactly the redeem condition I am setting on my coins is. P2SH works like this. I take the script that I want to be my `scriptPubKey` and I serialize it (I'll use {} to denote serialization):

```
redeemScript = {OP_3 {pubkey1} {pubkey2} {pubkey3} {pubkey4} {pubkey5} OP_5 OP_CHECKMULTISIG}
redeemScript_hash = hash160(sha256(redeemScript))

```

And then the `scriptPubKey` that the sender actually uses is:

```
OP_HASH160 {redeemScript_hash} OP_EQUAL

```

Which is just 23 bytes in total. The nice thing is that it provides a layer of abstraction. The person who is sending me coins doesn't need to know how I am keeping my coins secure. All they see is a hash of a `redeemScript`, but they don't know what conditions that `redeemScript` actually puts on redeeming the coins.

Basically, P2SH itself is not inherently more secure because the redeem script can be anything. But what it does is enable coin-receivers to easily communicate how coin-senders should send them coins, while letting the coin-receivers dictate the conditions of how/when those coins can be spent.


---

