How does P2SH unlocking work?

Question

"Mastering Bitcoin" by Antonopoulos in its P2SH section describes how the unlocking and locking scripts are executed and evaluated by nodes. The author gives this as example of an unlocking script:

<Sig1> <Sig2> <redeem-script>

and the locking script:

HASH160 <20-byte hash of redeem script> EQUAL

Then there's this:

The two scripts are combined in two stages. First, the redeem script is checked against the locking script to make sure the hash matches: [...]

Questions

• Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule. Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?
• If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?
• Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?
• Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Answer 1

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule. Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?

All scripts begin with the same verification process; the concatenate and evaluate. However P2SH has a special extra step. For P2SH outputs, the redeemScript (as part of the first script evaluation) is pushed to the top of the stack. It is then popped from the stack and evaluated as a script with whatever items are remaining in the stack after the first script validation.

Outputs are determined to be P2SH by the template of the output script. All P2SH outputs follow the same template

OP_HASH160 <hash> OP_EQUAL

Any output script that is in this template will be evaluated as a P2SH output. This means that after the first script evaluation pass (concatenate and evaluate), the top stack item is popped and evaluated as a script.

Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Kind of. Nodes that don't support P2SH would still validate the script as passing because the stack is non-empty and the top stack item is not 0 (OP_FALSE).

Answer 2

Does that mean that not all validations follow just plain "concatenate unlocking and locking script and execute' method of validation? As a beginner I'd expect that for uniformity and security all transactions should follow this same uniform rule.

Nothing uses the "concatenate unlocking and locking script and execute". That approach was abandoned in Bitcoin v0.3.7 (released in July 2010), as it was the reason for one of the two theft-enabling bugs Bitcoin had in its infancy.

The current approach is to first execute the unlocking script, look at the resulting stack, and then execute the locking script with that stack as initial stack. The resulting top stack item determines whether validation succeeded or not.

Based on the quote, it looks like the P2SH (or possibly other types) scripts are evaluated in a different manner?

It is not so much a different rule - just an additional rule. Because of backward compatibility, network rule upgrades can only add additional restrictions on previously-valid scripts. They can't make invalid scripts valid, as those would risk splitting the network in two (look up "softforks").

If the answer is yes, how does the Bitcoin node know which type of unlocking/locking script type should be applied for each particular transaction?

Whenever a spend (a) validates using normal rules and (b) has a locking script that satisfies a specific pattern, defined in BIP16, an addition P2SH-specific execution follows, whose validation result is what matters.

Also, if the answer is yes, are there other deviations from the plain "concatenate and execute" rule?

This same approach is used for a much more recent network rule improvement, called SegWit, specified in BIP141, which is expected to be activated on the network around August 22nd 2017.

Say there's a very old legacy node that's not P2SH enabled. The transaction above would still evaluate to true (if the provided redeem script is right) as the stack would have a TRUE on top at the end of execution?

Yes, by definition, because P2SH only adds additional restrictions. The specific P2SH locking script just checks whether the spender knows the "embedded" unlocking script (also called redeemscript).