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

user11123: 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! 

user120: The P2SH, as defined in BIP 16, 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 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 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.

1760: <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>
 11123: <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>
 120: <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>
