Combining the spending transaction scriptSig and funding transaction scriptPubKey, we get:
<OP_0> <sig A> <sig C> <redeemScript> <OP_HASH160> <redeemScriptHash> <OP_EQUAL>
Stepping through this script:
1)OP_0 and the two signatures are added to the stack, kept for later.
2)The redeemScript is added to the stack.
3)OP_HASH160 hashes our redeemScript.
4)redeemScriptHash is added to the stack.
5)OP_EQUAL will compare OP_HASH160(redeemScript) and redeemScriptHash and check for equality. This confirms that our spending transaction is providing the correct redeemScript.
6)Now our redeemScript can be evaluated:
<OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> <OP_CHECKMULTISIG>
7)OP_CHECKMULTISIG will look at the 3 public keys and 2 signatures in the stack, and compare them one by one. As stated earlier, the order of signatures matters here and must match the order that the public keys were provided in.
8)OP_0 is included only to deal with an off-by-one error in Bitcoin Core when using OP_CHECKMULTISIG.
i read several answers related to this topic and i read also the BIP16 but i still can not understand how after validation with
<redeemScript> calculated with
<redeemScriptHash> the script continues with the validation of
<sig A> <sig C>
After the procedure which i have already described the only portions left in the stack are :
<OP_0> <sig A> <sig C> How these signatures will be verified since the fact that
<redeemScript> is poped out of the stack?
My question in other words has to do with step 6. Now our redeemScript can be evaluated: how since it has been removed from the stack...