<p>The script in the output is created first. Its form is typically:</p>

<p>OP_DUP, OP_HASH160, <strong>pubKeyHash</strong>, OP_EQUALVERIFY, OP_CHECKSIG</p>

<p><strong>pubKeyHash</strong> is the hash contained in the address being sent to. So it is the hash of the public key of the receiver.</p>

<p>When this receiver wants to spend this output, he must construct an input to claim it, and provide the actual public key that corresponded to his hash, and signature using it:</p>

<p><strong>signature</strong>, <strong>pubKey</strong></p>

<p>Twice, the same public key data is used. Once by the sender, stating the hash of the public key of the receiver, and when the receiver becomes a sender himself, he provides his full public key.</p>

CC BY-SA 3.0
2013-03-29T09:27:35.630Z
Thanks Pieter. Then the OP_EQUALVERIFY it's only when the receiver's become in sender and he needs to construct an input no? This is a little confusing. Sorry for my incomprehension.
Zanetti
CC BY-SA 3.0
2013-03-29T13:31:52.687Z
I see that in the wiki:


Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.


The OP_EQUALVERIFY checked the previous ScriptPubKey of this transaction with the ScriptSig of the new transaction no? Because the previous transaction's receiver is a new transaction sender, and in this form I can understand if you compare the whole public key of the new transaction (ScriptSig) with the previous transaction PubKeyHash it must be the same.
I'm right now?

Thanks
Zanetti
CC BY-SA 3.0
2013-03-29T16:45:39.803Z
That is correct.
Pieter Wuille
CC BY-SA 3.0
2013-03-28T16:05:48.197Z
2013-03-28T16:05:48.197Z
Pieter Wuille
<p>I think I got confused in the same manner, probably due to how the current bitcoin wiki on <a href="https://en.bitcoin.it/wiki/Transactions" rel="nofollow">Transactions</a> is written, so I think I can explain. </p>

<p>In every Bitcoin transaction, there is an input and output. The output contains the Bitcoin script (instructions for sending) so it contains the receiver's Bitcoin address. Input contains a reference to the previous output where the Bitcoins will be sent from, along with a signature to prove that the sender owns that address.  So let's say we have two transactions. A and B. </p>

<p>[Input A / Output A] -> [Input B (referencing Output A) / Output B]</p>

<p>When a Bitcoin nodes receives transaction B, it runs a script using output A and Input B (input B is put on the top of the stack, and output A on the bottom). It seems that you are thinking that the script gets run on Input B and Output B, but this would clearly fail when running OP_EQUALVERIFY. </p>

CC BY-SA 3.0
2014-07-13T18:28:07.850Z
2014-07-13T18:36:42.537Z
2014-07-13T18:36:42.537Z
k kurokawa
<p>3 weeks ago I began learning about Bitcoins, and now I'm analyzing how it works internally. My problem is that I can't understand what two public key hashes are compare to use de OP_EQUALVERIFY, because I understand that sender's public key is compare with receiver's public key, but they aren't the same hash.</p>

<p>Here is an example:
A script is: the scriptSig of your tx + the scriptPubkey of the tx you spent</p>

<p>In the same example:
The scriptSig of your tx is: Sig + your pubkey
The scriptPubkey of the tx you spent is (according to blockexplorer): </p>

<pre><code>OP_DUP OP_HASH160 fc88853163ab2a9646908a82e8a87b6f185c2047 OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

<p>I hope </p>

<pre><code>ripemd160(sha256('0x0457d7d7af586aaad529b5770bb43295051e7090e2bc884181d608dae2517c7812b25e326753cbe0b767f579bbcb5cffe492d22b93f2ff5501074eb9e8f8547c4a'))  
 = fc88853163ab2a9646908a82e8a87b6f185c2047...
</code></pre>

<p>I read that but I can't understand that the stack and scripts function. 
The stack is empty. On the first step the Sender’s Signature and Public Key are combined. Then these two constants are added in the stack. Then the Public Key is duplicated. After that this duplicated item is hashed. Now the Receiver´s Public Key Hash is added to the stack. The script compares the equality between the two slack items and finally the signature is checked for two slack items.</p>

<p>Is that correct? I think that i'm wrong with something.
If it is posible to someone answer or reply me</p>

<p>Thanks.</p>

<script><transaction-input><p2pkh>
How OP_EQUALVERIFY works in a standard transaction?
Zanetti
# How OP_EQUALVERIFY works in a standard transaction?

(Asked by: username_0 on 2013-03-28)

3 weeks ago I began learning about Bitcoins, and now I'm analyzing how it works internally. My problem is that I can't understand what two public key hashes are compare to use de OP\_EQUALVERIFY, because I understand that sender's public key is compare with receiver's public key, but they aren't the same hash.

Here is an example:
A script is: the scriptSig of your tx + the scriptPubkey of the tx you spent

In the same example:
The scriptSig of your tx is: Sig + your pubkey
The scriptPubkey of the tx you spent is (according to blockexplorer):

```
OP_DUP OP_HASH160 fc88853163ab2a9646908a82e8a87b6f185c2047 OP_EQUALVERIFY OP_CHECKSIG

```

I hope

```
ripemd160(sha256('0x0457d7d7af586aaad529b5770bb43295051e7090e2bc884181d608dae2517c7812b25e326753cbe0b767f579bbcb5cffe492d22b93f2ff5501074eb9e8f8547c4a'))  
 = fc88853163ab2a9646908a82e8a87b6f185c2047...

```

I read that but I can't understand that the stack and scripts function.
The stack is empty. On the first step the Sender’s Signature and Public Key are combined. Then these two constants are added in the stack. Then the Public Key is duplicated. After that this duplicated item is hashed. Now the Receiver´s Public Key Hash is added to the stack. The script compares the equality between the two slack items and finally the signature is checked for two slack items.

Is that correct? I think that i'm wrong with something.
If it is posible to someone answer or reply me

Thanks.

**Tags:** script, transaction-input, p2pkh


---

## 2 answers

### Answer by username_1 on 2013-03-28. Score: 8

The script in the output is created first. Its form is typically:

OP\_DUP, OP\_HASH160, **pubKeyHash**, OP\_EQUALVERIFY, OP\_CHECKSIG

**pubKeyHash** is the hash contained in the address being sent to. So it is the hash of the public key of the receiver.

When this receiver wants to spend this output, he must construct an input to claim it, and provide the actual public key that corresponded to his hash, and signature using it:

**signature**, **pubKey**

Twice, the same public key data is used. Once by the sender, stating the hash of the public key of the receiver, and when the receiver becomes a sender himself, he provides his full public key.

> **Comments:**
> **username_0**: Thanks username_1. Then the OP_EQUALVERIFY it's only when the receiver's become in sender and he needs to construct an input no? This is a little confusing. Sorry for my incomprehension.  
> **username_0**: I see that in the wiki:   Note: scriptSig is in the input of the spending transaction and scriptPubKey is in the output of the previously unspent i.e. "available" transaction.   The OP_EQUALVERIFY checked the previous ScriptPubKey of this transaction with the ScriptSig of the new transaction no? Because the previous transaction's receiver is a new transaction sender, and in this form I can understand if you compare the whole public key of the new transaction (ScriptSig) with the previous transaction PubKeyHash it must be the same. I'm right now?  Thanks  
> **username_1**: That is correct.  

---

### Answer by username_2 on 2014-07-13. Score: 2

I think I got confused in the same manner, probably due to how the current bitcoin wiki on [Transactions](https://en.bitcoin.it/wiki/Transactions) is written, so I think I can explain.

In every Bitcoin transaction, there is an input and output. The output contains the Bitcoin script (instructions for sending) so it contains the receiver's Bitcoin address. Input contains a reference to the previous output where the Bitcoins will be sent from, along with a signature to prove that the sender owns that address. So let's say we have two transactions. A and B.

[Input A / Output A] -> [Input B (referencing Output A) / Output B]

When a Bitcoin nodes receives transaction B, it runs a script using output A and Input B (input B is put on the top of the stack, and output A on the bottom). It seems that you are thinking that the script gets run on Input B and Output B, but this would clearly fail when running OP\_EQUALVERIFY.


---

