<p>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 <a href="https://blockchain.info/tx/ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6" rel="nofollow noreferrer">https://blockchain.info/tx/ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6</a>. The scriptPubKey of that output is</p>

<pre><code>04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG 
</code></pre>

<p>To evaluate the input script, we concatenate the input script with the output script, so our final script is</p>

<pre><code>3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG 
</code></pre>

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

<p>So the stack now looks like</p>

<pre><code>04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 
</code></pre>

<p>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.</p>

<hr>

<p>For a P2PKH transaction, lets use the second input of <a href="https://blockchain.info/tx/12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6" rel="nofollow noreferrer">https://blockchain.info/tx/12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6</a>. This points us to the first output of <a href="https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516" rel="nofollow noreferrer">https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516</a> which is a P2PKH output.</p>

<p>The output script is</p>

<pre><code>OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG 
</code></pre>

<p>and the input script is</p>

<pre><code>304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
</code></pre>

<p>Concatenating the two scripts gets us a final script of </p>

<pre><code>304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

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

<pre><code>044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 
</code></pre>

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

<pre><code>044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601
</code></pre>

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

<pre><code>12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601
</code></pre>

<p>The 20 byte hash is not pushed to the stack, so we get</p>

<p>that item, so our stack now looks like </p>

<pre><code>12ab8dc588ca9d5787dde7eb29569da63c3a238c
12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601
</code></pre>

<p>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</p>

<pre><code>044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601
</code></pre>

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

<pre><code>OP_TRUE
</code></pre>

<p>as our stack. And thus the script execution is successful.</p>

<hr>

<p>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.</p>

CC BY-SA 3.0
2017-08-11T09:00:32.523Z
Hi, could you explain why the output script (if you scroll to the bottom of the page I linked in my question) has OP_HASH160 if this is a pay to public key transaction?
user1936752
CC BY-SA 3.0
2017-08-11T09:08:58.910Z
The output scripts of this transaction don't matter. What matters are the output scripts of the transactions that the inputs of this transaction spend from..
Ava Chow
CC BY-SA 3.0
2017-08-11T10:03:11.750Z
Great, thank you. Can I check how you found that the parent transaction was "ff3dc8b461305ac..."? I could not find that txid anywhere on the page I linked in my question. Also, if it's not too much trouble, can you add to your answer how this would be different if we were doing a P2PKH instead i.e. now in the output, instead of a pubKey and OP_CHECKSIG, I have OP_DUP OP_HASH160 a hash etc. so what exactly do I concatenate with the signature?
user1936752
CC BY-SA 3.0
2017-08-13T05:05:40.687Z
On blockchain.info, you can scroll down to the bottom and click the link to enable Advanced View. Advanced View will show you the input and output scripts, links to the output that an input spends from, and links to the transaction that spends an output.
Ava Chow
CC BY-SA 3.0
2017-08-10T17:28:38.780Z
2017-08-13T05:21:33.273Z
2017-08-13T05:21:33.273Z
Ava Chow
<p>As an example, I would like to consider this transaction: <a href="https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516" rel="nofollow noreferrer">https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516</a></p>

<p>I have three questions:</p>

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

<pre><code>3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01
</code></pre>

<p>Where are the two separate items, the signature and the public key?</p>

<p>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 <code>&lt;pubKey&gt;</code>, I'd like to actually run OP_HASH160 and see that I get the result <code>12ab8dc588ca9d5787dde7eb29569da63c3a238c</code> using a tool like this <a href="http://bitcoinvalued.com/tools.php" rel="nofollow noreferrer">http://bitcoinvalued.com/tools.php</a>. Where exactly is the <code>&lt;pubKey&gt;</code> that yields this hash? </p>

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

<transactions><script>
Walking through a transaction script
user1936752
# Walking through a transaction script

(Asked by: username_0 on 2017-08-08)

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?

**Tags:** transactions, script


---

## 1 answers

### Answer by username_1 on 2017-08-10. Score: 5 | Accepted answer

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.

> **Comments:**
> **username_0**: Hi, could you explain why the output script (if you scroll to the bottom of the page I linked in my question) has OP_HASH160 if this is a pay to public key transaction?  
> **username_1**: The output scripts of this transaction don't matter. What matters are the output scripts of the transactions that the inputs of this transaction spend from..  
> **username_0**: Great, thank you. Can I check how you found that the parent transaction was "ff3dc8b461305ac..."? I could not find that txid anywhere on the page I linked in my question. Also, if it's not too much trouble, can you add to your answer how this would be different if we were doing a P2PKH instead i.e. now in the output, instead of a pubKey and OP_CHECKSIG, I have OP_DUP OP_HASH160 a hash etc. so what exactly do I concatenate with the signature?  
> **username_1**: On blockchain.info, you can scroll down to the bottom and click the link to enable Advanced View. Advanced View will show you the input and output scripts, links to the output that an input spends from, and links to the transaction that spends an output.  

---

