Walking through a transaction script

Question

As an example, I would like to consider this transaction: https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516

I have three questions:

1) The first two entries in the stack are <sig> and <pubKey> for each input. However, the inputs are just giant strings. For the first of the two inputs, it is

3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

Where are the two separate items, the signature and the public key?

2) I understand that OP_DUP duplicates the top item on the stack i.e. the publick key and then OP_HASH160 computes the hash. Assuming I have the <pubKey>, I'd like to actually run OP_HASH160 and see that I get the result 12ab8dc588ca9d5787dde7eb29569da63c3a238c using a tool like this http://bitcoinvalued.com/tools.php. Where exactly is the <pubKey> that yields this hash?

3) Finally, there is the OP_CHECKSIG which should take , and and return true or false. Where exactly are these items in this transaction?

Answer 1

This transaction is a Pay-to-pubkey transaction, so there is no OP_DUP and no OP_HASH160. When validating an input, you first need to find the scriptPubKey of the output that this input spends from. The first input of your transaction spends from the first output of https://blockchain.info/tx/ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6. The scriptPubKey of that output is

04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG 

To evaluate the input script, we concatenate the input script with the output script, so our final script is

3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG 

The first array of bytes (3046...5d01) is the signature. That is first pushed to the stack. Then the second array of bytes (04c9...ff6d) is pushed to the stack; that is the public key.

So the stack now looks like

04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 

Lastly OP_CHECKSIG is performed. It pops the top two items on the stack. The first item popped is treated as the public key (and in this case it is the actual public key) and the second item popped is treated as a signature (and in this case it is the actual signatures). Then the signature is verified, and if it is, OP_TRUE is pushed to the stack.

---

For a P2PKH transaction, lets use the second input of https://blockchain.info/tx/12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6. This points us to the first output of https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516 which is a P2PKH output.

The output script is

OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG 

and the input script is

304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c

Concatenating the two scripts gets us a final script of

304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

So following the execution, the first two items (the signature and pubkey) are pushed to the stack, so our stack is

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 

OP_DUP tells us to duplicate the top item (the pubkey), so our stack is now

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_HASH160 pops the top stack item and pushes the RIPEMD160 of the SHA256 of that item, so our stack now looks like

12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

The 20 byte hash is not pushed to the stack, so we get

that item, so our stack now looks like

12ab8dc588ca9d5787dde7eb29569da63c3a238c
12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_EQUALVERIFY pops the top 2 stack items and checks that they are equal. If they are not equal, the script execution bails out and fails. Otherwise nothing else happens. So now our stack is

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

Lastly we do OP_CHECKSIG like we did with the P2PK output. The signature verifies, so we are left with

OP_TRUE

as our stack. And thus the script execution is successful.

---

Also, it is important to note that script execution is no longer actually concatenating the input and output scripts. Rather the input script is first verified, and then its resulting stack is examined for whether it is valid (i.e. there were no errors validating the input script) then that stack is passed as an initial stack to the output script verifier and the output script is run.