What is relation between scriptSig and scriptPubKey? Scenario: A is sending 1 BTC to B.

scriptSig appears in the Input Script.

scriptSig = &lt;sig&gt; &lt;pubKey&gt;



Here, public key is the Public Key of the sender, A. (this is the public key corresponding to his Bitcoin Address which has some unspent transaction).


What is the sig part of scriptSig?

scriptPubKey

scriptPubKey = OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG


pubKeyHash = Hash of the Public Key of Recipient (in our case, B).


The sender (A) only has the Bitcoin Address of the recipient (B), so how does he get the pubKeyHash from his Bitcoin Address?


Now, this is my understanding so far:


Input Script carries information about the "previous transaction" of the sender and points to the appropriate "output" part of "previous transaction" using an index. The output of the previous transaction is the total available balance for the sender (A) which can be claimed to send Bitcoins to the recipient (B).
This Input Script is also used to verify that the sender (A) is the actual owner of the Bitcoins held in the referenced output of previous transaction.
Output Script tells us, how many bitcoins the Sender wants to Transfer to the Recipient and it also mentions the Bitcoin Address of recipient.


Questions:


The public Key in scriptSig is different from the public Key in scriptPubKey?
How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?
I have tried understanding the example given on wiki which shows how the script is executed in a stack based manner but could not understand it.


I have some more questions, but I think I will ask them in a different question instead of putting it altogether here.

Thanks.
First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend the bitcoins associated with the output if he can prove that he owns the output.

This is where Transaction B and the scriptSig comes into play. Assuming a user wants to send some funds somewhere. He creates a new transaction, and adds outputs to it until he has enough to cover the desired amount. Now he has to prove that he owns those outputs, which he does by providing the output that is needed to claim them, i.e., the public key matching the address and the signatures with the matching private key.

The sender of Transaction A does not yet know the public key, but does know a hash of the public key, because he knows the address he wants to send to. The address is nothing more than the hash of the public key. So the sender now knows all he needs to be able to send the funds to the receiver.

When the receiver wants to spend the funds again he provides the input to the scriptPubKey. As you can see the scriptPubKey consists of taking the public key that was pushed on the stack, duplicating it, hashing it and comparing it to the hash of the public key the output was destined for. If they match we still have both the signature and the public key on the stack, which are used by OP_CHECKSIG to see whether the input had a valid signature attached.

Take this transaction for example. It claims one output, by providing the public key and the matching signature. It then creates two new outputs and specifies the conditions for the next user to claim them.