Verifying a P2SH transaction script by hand. How should I concatenate OP CODES in order to hash the script?

Question

I'm reading this:

Transaction 40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8 paid to P2SH address 3P14159f73E4gFr7JterCCQh9QjiTjiZrG. You can see the redeem script in transaction 7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45 which spends that output, using OP_FALSE { OP_1 OP_1 OP_CHECKMULTISIG }.

from https://en.bitcoin.it/wiki/Pay_to_script_hash

I'm trying to check the validity of the transactions by hand to see if I understand what's happening. I first found the first transaction: https://blockchain.info/tx/40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8

As I understood, it is locking these outputs to the output script

OP_HASH160 e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a OP_EQUAL 

The text tells me to look at the other transaction: https://blockchain.info/tx/7edb32d4ffd7a385b763c7a8e56b6358bcd729e747290624e18acdbe6209fc45

which spends this output. It means that this transaction presents a script (with data) that satisfies OP_HASH160 e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a OP_EQUAL. Let's see the input of this transaction:

OP_FALSE 3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001 5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

I should take the OP_HASH160 of this to verify it's equal to e9c3dd0c07aac76179ebc76a6c78d4d67c6c160a, right? Remember that OP_HASH160 means: ripemd160(sha256(something)). Should I concatenate that OP_FALSE int he beggining? Also, shouldn't it be a script? Where are the other op_codes beasides OP_FALSE?

Answer 1

You can find the execution of a similar pay to script hash (P2SH) transaction here: Pay to Script Hash Execution

Basically the scriptSig is evaluated first, it pushes an empty array of bytes onto the stack because of the OP_FALSE code, and then pushes the signature 3045....001 onto the stack, and finally pushes the redemption script 5141...1ae on. Then we move on to the scriptPubKey evaluation, the encoded redemption script is taken off the stack and hashed, and the hash is compared to the hash e9c3...60a. if these are equal, we move on to the actual evaluation of the redemption script. This means the stack is taken back to the point before the scriptPubKey execution, so we have:

 5141...1ae
 3045....001
 (empty value)

The top element is popped off, decoded, and then evaluated. In this case, it is a OP_CHECKMULTISIG script, the decoded version is on the webpage you linked as well as in your question, but this multisig only has one public key and one signature, so it's basically equivalent to paying straight to that one address. The OP_CHECKMULTISIG will check the signature 3045...001 against the public key, and if it matches, the transaction is valid. The empty data pushed on at the start by OP_FALSE is simply there due to CHECKMULTISIG taking one more element off than it needs, due to a bug, so it's just an unused bit of data needed to make it work.

I'm not sure what you mean by it being a script. It is a script, it is just encoded in the 5141...1ae. You can decode it with the decodescript call on bitcoin RPC.