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 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?

  • 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
    Mar 31 '15 at 20:37
  • 1
    Acording to Bitcoin's documentation: "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. Mar 31 '15 at 21:26
  • @randomname453 If it didn't say "security" I'd argue it's referring to data storage in the Blockchain using multisig Apr 1 '15 at 8:40
  • 1
    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. Apr 1 '15 at 11:02
  • 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: github.com/bitcoin/bitcoin.org/commit/… Apr 1 '15 at 13:29

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.