How OP_EQUALVERIFY works in a standard transaction?

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.

Zanetti

Posted 2013-03-28T15:59:06.110

Reputation: 71

Answers

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.

Pieter Wuille

Posted 2013-03-28T15:59:06.110

Reputation: 54 032

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 – 2013-03-29T09:27:35.630

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 – 2013-03-29T13:31:52.687

That is correct. – Pieter Wuille – 2013-03-29T16:45:39.803

I think I got confused in the same manner, probably due to how the current bitcoin wiki on 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.

kaykurokawa

Posted 2013-03-28T15:59:06.110

Reputation: 1 902