5

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 <OP_EQUAL>of <redeemScript> calculated with <OP_HASH160> and <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...

8

I've been hunting for this information myself, and had to dig to the bitcoin source code to find the answer - couldn't find it anywhere else.

There is a hardcoded logic in bitcoin for P2SH validation:

The stack is backed up between the steps 2 and 3 (generally - between scriptSig and scriptPubKey execution).

After both scripts are executed and verified, the stack is restored from the earlier backup, the redeem script is popped from the stack, deserialized, executed and verified. This is done by internal bitcoin code, not by any script.

Corresponding source code: https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp

Stack is backed up at 1412, and restored at 1448, where all the magic begins.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.