Pay to script hash is a special payment destination that consists of two constraint scripts. The first is the output script which must follow a specific form that is recognised by bitcoin software. This output script requires a parameter which is actually another constraint script, called the redeem script. To spend a P2SH output, the input script therefore supplies the redeem script and additional data as stack parameters. The bitcoin software verifies that the redeem script’s hash matches that in the output script, and then executes the redeem script (which uses the additional data pushed by the input script). Since the redeem script stack item is executed without any explicit instruction to do so, the P2SH script form breaks the original script execution model.

Comparison with P2PKH

The P2SH form places all interesting constraints in the redeem script, whereas previously these constraints were placed in the output script. It is arguably better to place constraints in the redeem script for several reasons:

1. Simple Addresses: P2SH allows the receiver to have funds sent to any constraint script, by providing the sender with an address. Previously, a new address form had to be created for every new script type, or in theory the entire constraint script could be sent from receiver to sender (no protocol to do this has been specced or implemented).
2. Information Containment: In the original model, the sender places constraints on the receiver’s next spend. But what the receiver does with the money next is and should be irrelevant to the sender, except in special circumstances. In those circumstances, P2SH still works – the receiver and sender can agree on the redeem script beforehand.
3. Space Efficiency: P2SH defers providing the redeem script until it is used, replacing it with a 20 byte hash. For non-trivial scripts, this will make the UTXO set smaller.
4. Privacy: P2SH does not reveal the script contents until it is spent. One drawback of this is that it is not possible to determine whether certain instructions are in use or not. This makes retirement of opcodes impossible. However, its also possible for people to create transactions and not commit them to the blockchain, so the viability of opcode retirement is questionable anyway.