<p>I recall some of these transactions and researched them. </p>

<p>P2SH was introduced as a soft-fork, meaning old nodes technically didn't have to upgrade - the soft fork could be carried out by a hashrate majority of miners. </p>

<p><code>OP_HASH160 [20 byte hash] OP_EQUAL</code></p>

<p>This is the P2SH scriptPubKey. Before the soft-fork, it meant that anyone that knew the value that hashed to <code>[20 byte hash]</code> could spend the coins. </p>

<p>A quick note on hashrate-majority enforced soft-forks. These are normally invisible to clients unaware of them. The reason is, these soft-forks usually only forbid certain things from happening, rather than allow something new and unexpected to happen. </p>

<p>P2SH is one of these types, because it added further rules to the above snippet of Bitcoin Script. The rule is, if the value hashes to <code>[20 byte hash]</code>, <em>then assume it is a string of bitcoin script and verify it</em>. All this does is prevent some spend attempts from entering the blockchain - they might fail P2SH validation. </p>

<p>From an old version's point of view, if something you allow never happens again, there is no rule violation. </p>

<p>So, why was this block 'mined' 94 times? Well, partially because Blockchain.info uses confusing terminology. They received 94 blocks including this transaction. It's just a pity they were all orphaned!</p>

<p>This is an unfortunate case where the hashrate-majority soft-fork actually caused problems for someone. That someone was in the minority running v0.6, and kept running the older software version (or they forgot to upgrade). Their software a transaction with a valid pre-image for [20 byte hash], and accepted it into the mempool. It then tried to mine it. </p>

<p>The majority, however, had just accepted a rule where such transactions are exposed to additional validation, and deemed this transaction invalid, so they refused to build on top of these blocks.</p>

<p>Regarding P2SH addresses, they are very useful these days. You can request someone to fund a complicated script (like multisig, or a Lightning channel) using a fixed-size address! </p>

CC BY-SA 3.0
2017-02-13T14:13:08.140Z
Is segwit not a hashrate-majority enforced soft-fork? I can't understand how it is only forbidding and not allowing something new.
Janus Troelsen
CC BY-SA 3.0
2017-02-14T16:27:58.937Z
Right now you can pay to `OP_0 [32 bytes]` and miners would put your spend in a block without you providing a signature. (though, we wouldn't softfork that script if someone was using it)

With segwit activating, outputs with this script are no longer accepted without scrutiny - the new rules are applied (must provide a VALID witness now), so that only non-rule violations are included in blocks. 

To old nodes, there is nothing new happening. Just the absence of something it didn't care about.
karimkorun
CC BY-SA 3.0
2017-02-14T16:30:22.183Z
Same as P2SH - old nodes who would have accepted spends of `OP_HASH160 [HASH] OP_EQUAL` before activation would accept any transaction with no signature. Afterwards, they wouldn't realize that all the signatures which would fail P2SH evaluation aren't around anymore.
karimkorun
CC BY-SA 3.0
2017-07-29T05:03:25.240Z
Going to be lolz epic when [all the SegWit transactions are double-spent, i.e. stolen](https://steemit.com/bitcoin/@anonymint/re-anonymint-the-real-bitcoin-which-bitcoin-fork-will-win-20170728t173016687z) by miners on The Real Bitcoin (the legacy Satoshi blockchain).
Shelby Moore III
CC BY-SA 3.0
2018-01-15T00:54:15.107Z
Please follow our "Be Nice" policy, that's not an appropriate way to address people
meshcollider
CC BY-SA 3.0
2018-02-10T13:41:52.347Z
I want to know more about segwit. And soft fork, hard fork differences, meaning. Eventually, how to apply them from programmer point of view.
creator
CC BY-SA 3.0
2018-02-11T13:32:33.763Z
Segwit is in some ways similar to P2SH if you compare them. Look at the reference code. Your other questions probably warrant a separate question :)
karimkorun
CC BY-SA 3.0
2015-10-01T16:54:24.990Z
2015-10-01T16:54:24.990Z
karimkorun
<p>The P2SH, as defined in <a href="https://en.bitcoin.it/wiki/BIP_0016">BIP 16</a>, states that</p>

<blockquote>
  <p>The purpose of pay-to-script-hash is to move the responsibility for
  supplying the conditions to redeem a transaction from the sender of
  the funds to the redeemer.</p>
  
  <p>The benefit is allowing a sender to fund
  any arbitrary transaction, no matter how complicated, using a
  fixed-length 20-byte hash that is short enough to scan from a QR code
  or easily copied and pasted.</p>
</blockquote>

<p>Hence it allows any client implementation to fund a transaction with an arbitrary script, without the client necessarily having to understand it. You see, there are some quite <a href="https://en.bitcoin.it/wiki/Contracts">complicated possibilities</a> for transactions to state their claiming conditions, which may put different implementations of clients under a dilemma: each time a new script type surfaces they'd have to implement it so that the client can send transactions that make use of them.</p>

<p>P2SH has the advantage that the client does not necessarily have to know how to build such a script, it just has to know how (given an arbitrary script, or indeed its hash) building a script that first verifies the script and then uses that script to verify the claim itself works.</p>

<p>Suddenly, if I provide you with a hash of a claiming condition (script) you can send me bitcoins without actually having to know what security mechanisms I put in place to secure that only I can then spend them.</p>

<p>As an added bonus it really keeps the addresses small (25 byte script) which can easily be displayed in a QR code or may even be typed by hand.</p>

<p>The reason transaction <a href="https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2">4005d6be</a> is included in so many blocks is all of those blocks are orphaned, so the miners that included them supported a version of P2SH but never got a majority. The fact that this transaction is still unconfirmed is probably due to it being not a true P2SH script.</p>

CC BY-SA 3.0
2013-04-13T15:20:38.723Z
Oh! Amazing. Another question: How much is P2SH supported today? What all can I write to the encoded script? I found out that miners won't accept any arbitrary script, is the same thing true about the encoded scripts?
Karel Bílek
CC BY-SA 3.0
2013-04-13T15:40:06.417Z
That's a good question. While you can specify a hash of an arbitrary script to be a claiming condition we have to make sure that the script is valid, otherwise you won't be able to spend those coins ever again.
cdecker
CC BY-SA 3.0
2014-07-22T22:58:19.473Z
@cdecker could you elaborate on that second paragraph of yours that begins "P2SH has the advantage that..."? Is the client the one sending the bitcoins, or the redeemer? Can you give an example of what type of script they wouldn't have to build, and then also give an example of the script that verifies the first script?
almel
CC BY-SA 3.0
2014-07-23T10:47:15.517Z
Let's say the sender has a really old wallet, that does not support multisig addresses. Using P2SH the receiver creates the hash of a script that does multisig, uses it to create a P2SH address and sends it to the sender. The sender now has an address, which is a valid P2SH address, and can send funds to it, even though it does not know anything about multisig addresses. For an example I'd like to point you to the examples in [BIP 16](https://en.bitcoin.it/wiki/BIP_0016).
cdecker
CC BY-SA 3.0
2017-06-10T03:01:56.930Z
You said a "client does not necessarily have to know how to build such a script".  If I use a beta wallet that uses P2SH addresses, and they make a mistake where the script is miscalculated and can't spend the funds... or is it more foolproof than that and I'm needlessly paranoid?
Brain2000
CC BY-SA 3.0
2017-06-10T11:41:17.500Z
Well that comes down to how much you trust the wallet you as a recipient are using :-) It's similar to your P2PKH wallet having a mistake in the hash computation, or it using the wrong pubkey, or it deriving the pubkey wrongly from the privkey. That being said, wallets are thoroughly tested before being released, so I wouldn't worry too much if you use a well tested wallet implementation
cdecker
CC BY-SA 3.0
2018-02-10T13:34:56.273Z
@cdecker hi, I am also programmer, I have talk to you about making crypto currency. What is your contact? or send me email  [ wsxdrfv (at) hanmail (dot) net ] Thanks.
creator
CC BY-SA 3.0
2013-04-13T12:37:44.593Z
2013-04-13T12:37:44.593Z
cdecker
<p>I found out this address playing with blockchain</p>

<p><a href="https://blockchain.info/address/3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8">https://blockchain.info/address/3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8</a></p>

<p>I found out it's something called "scripthash". How does it work exactly? How does it differ from a normal address?</p>

<p>I found out this - <a href="https://en.bitcoin.it/wiki/BIP_0016">https://en.bitcoin.it/wiki/BIP_0016</a> - but I still don't get it and I don't get the point. </p>

<blockquote>
  <p>The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.</p>
</blockquote>

<p>How does it differ from what <em>is</em> possible today - scanning just the address of the reciever?</p>

<p>edit: And adding one more question - why exactly is this transaction with the mentioned address as input</p>

<p><a href="https://blockchain.info/tx-index/3618498">https://blockchain.info/tx-index/3618498</a></p>

<p>included in <em>94 different blocks</em>? How does that even work?</p>

<transactions><script><hash>
What is "Script Hash" address exactly and how does it work?
Karel Bílek
# What is "Script Hash" address exactly and how does it work?

(Asked by: username_0 on 2013-04-13)

I found out this address playing with blockchain

<https://blockchain.info/address/3NukJ6fYZJ5Kk8bPjycAnruZkE5Q7UW7i8>

I found out it's something called "scripthash". How does it work exactly? How does it differ from a normal address?

I found out this - <https://en.bitcoin.it/wiki/BIP_0016> - but I still don't get it and I don't get the point.

> The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted.

How does it differ from what *is* possible today - scanning just the address of the reciever?

edit: And adding one more question - why exactly is this transaction with the mentioned address as input

<https://blockchain.info/tx-index/3618498>

included in *94 different blocks*? How does that even work?

**Tags:** transactions, script, hash


---

## 2 answers

### Answer by username_6 on 2013-04-13. Score: 13 | Accepted answer

The P2SH, as defined in [BIP 16](https://en.bitcoin.it/wiki/BIP_0016), states that

> The purpose of pay-to-script-hash is to move the responsibility for
> supplying the conditions to redeem a transaction from the sender of
> the funds to the redeemer.
>
> The benefit is allowing a sender to fund
> any arbitrary transaction, no matter how complicated, using a
> fixed-length 20-byte hash that is short enough to scan from a QR code
> or easily copied and pasted.

Hence it allows any client implementation to fund a transaction with an arbitrary script, without the client necessarily having to understand it. You see, there are some quite [complicated possibilities](https://en.bitcoin.it/wiki/Contracts) for transactions to state their claiming conditions, which may put different implementations of clients under a dilemma: each time a new script type surfaces they'd have to implement it so that the client can send transactions that make use of them.

P2SH has the advantage that the client does not necessarily have to know how to build such a script, it just has to know how (given an arbitrary script, or indeed its hash) building a script that first verifies the script and then uses that script to verify the claim itself works.

Suddenly, if I provide you with a hash of a claiming condition (script) you can send me bitcoins without actually having to know what security mechanisms I put in place to secure that only I can then spend them.

As an added bonus it really keeps the addresses small (25 byte script) which can easily be displayed in a QR code or may even be typed by hand.

The reason transaction [4005d6be](https://blockchain.info/tx/4005d6bea3a93fb72f006d23e2685b85069d270cb57d15f0c057ef2d5e3f78d2) is included in so many blocks is all of those blocks are orphaned, so the miners that included them supported a version of P2SH but never got a majority. The fact that this transaction is still unconfirmed is probably due to it being not a true P2SH script.

> **Comments:**
> **username_0**: Oh! Amazing. Another question: How much is P2SH supported today? What all can I write to the encoded script? I found out that miners won't accept any arbitrary script, is the same thing true about the encoded scripts?  
> **username_6**: That's a good question. While you can specify a hash of an arbitrary script to be a claiming condition we have to make sure that the script is valid, otherwise you won't be able to spend those coins ever again.  
> **username_7**: @username_6 could you elaborate on that second paragraph of yours that begins "P2SH has the advantage that..."? Is the client the one sending the bitcoins, or the redeemer? Can you give an example of what type of script they wouldn't have to build, and then also give an example of the script that verifies the first script?  
> **username_6**: Let's say the sender has a really old wallet, that does not support multisig addresses. Using P2SH the receiver creates the hash of a script that does multisig, uses it to create a P2SH address and sends it to the sender. The sender now has an address, which is a valid P2SH address, and can send funds to it, even though it does not know anything about multisig addresses. For an example I'd like to point you to the examples in [BIP 16](https://en.bitcoin.it/wiki/BIP_0016).  
> **username_8**: You said a "client does not necessarily have to know how to build such a script".  If I use a beta wallet that uses P2SH addresses, and they make a mistake where the script is miscalculated and can't spend the funds... or is it more foolproof than that and I'm needlessly paranoid?  
> **username_6**: Well that comes down to how much you trust the wallet you as a recipient are using :-) It's similar to your P2PKH wallet having a mistake in the hash computation, or it using the wrong pubkey, or it deriving the pubkey wrongly from the privkey. That being said, wallets are thoroughly tested before being released, so I wouldn't worry too much if you use a well tested wallet implementation  
> **username_5**: @username_6 hi, I am also programmer, I have talk to you about making crypto currency. What is your contact? or send me email  [ wsxdrfv (at) hanmail (dot) net ] Thanks.  

---

### Answer by username_1 on 2015-10-01. Score: 6

I recall some of these transactions and researched them.

P2SH was introduced as a soft-fork, meaning old nodes technically didn't have to upgrade - the soft fork could be carried out by a hashrate majority of miners.

`OP_HASH160 [20 byte hash] OP_EQUAL`

This is the P2SH scriptPubKey. Before the soft-fork, it meant that anyone that knew the value that hashed to `[20 byte hash]` could spend the coins.

A quick note on hashrate-majority enforced soft-forks. These are normally invisible to clients unaware of them. The reason is, these soft-forks usually only forbid certain things from happening, rather than allow something new and unexpected to happen.

P2SH is one of these types, because it added further rules to the above snippet of Bitcoin Script. The rule is, if the value hashes to `[20 byte hash]`, *then assume it is a string of bitcoin script and verify it*. All this does is prevent some spend attempts from entering the blockchain - they might fail P2SH validation.

From an old version's point of view, if something you allow never happens again, there is no rule violation.

So, why was this block 'mined' 94 times? Well, partially because Blockchain.info uses confusing terminology. They received 94 blocks including this transaction. It's just a pity they were all orphaned!

This is an unfortunate case where the hashrate-majority soft-fork actually caused problems for someone. That someone was in the minority running v0.6, and kept running the older software version (or they forgot to upgrade). Their software a transaction with a valid pre-image for [20 byte hash], and accepted it into the mempool. It then tried to mine it.

The majority, however, had just accepted a rule where such transactions are exposed to additional validation, and deemed this transaction invalid, so they refused to build on top of these blocks.

Regarding P2SH addresses, they are very useful these days. You can request someone to fund a complicated script (like multisig, or a Lightning channel) using a fixed-size address!

> **Comments:**
> **username_2**: Is segwit not a hashrate-majority enforced soft-fork? I can't understand how it is only forbidding and not allowing something new.  
> **username_1**: Right now you can pay to `OP_0 [32 bytes]` and miners would put your spend in a block without you providing a signature. (though, we wouldn't softfork that script if someone was using it)  With segwit activating, outputs with this script are no longer accepted without scrutiny - the new rules are applied (must provide a VALID witness now), so that only non-rule violations are included in blocks.   To old nodes, there is nothing new happening. Just the absence of something it didn't care about.  
> **username_1**: Same as P2SH - old nodes who would have accepted spends of `OP_HASH160 [HASH] OP_EQUAL` before activation would accept any transaction with no signature. Afterwards, they wouldn't realize that all the signatures which would fail P2SH evaluation aren't around anymore.  
> **username_3**: Going to be lolz epic when [all the SegWit transactions are double-spent, i.e. stolen](https://steemit.com/bitcoin/@anonymint/re-anonymint-the-real-bitcoin-which-bitcoin-fork-will-win-20170728t173016687z) by miners on The Real Bitcoin (the legacy Satoshi blockchain).  
> **username_4**: Please follow our "Be Nice" policy, that's not an appropriate way to address people  
> **username_5**: I want to know more about segwit. And soft fork, hard fork differences, meaning. Eventually, how to apply them from programmer point of view.  
> **username_1**: Segwit is in some ways similar to P2SH if you compare them. Look at the reference code. Your other questions probably warrant a separate question :)  

---

