What is relation between scriptSig and scriptPubKey?

scriptSig = <sig> <pubKey>

What is the sig part of scriptSig?

It is the signature, made by A with his private key, of the content of the transaction he is creating, except for the scriptSig part (to not be recursive). It is made of <hash of the transaction from which an output is being used> <the index of this output in that transaction> <pubKey> <the current transaction output = <scriptPubKey> <1 BTC> >.

sciptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

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

You can find the <pubKeyHash> from the address because the final operations of the address creation do not obfuscate the input. It is merely a base58 encoding of the pubKeyHash padded with some data, i.e. address = base58_encode(<pubKeyHash> || <padding>), thus pubKeyHash = base58_decode(address) ^^ <padding>.

Your understanding is on point except for part:

1. 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).

The input script is scriptSig and does not carry the reference to the output being spent. This information is in the input of the current transaction but not formally in the unlocking script.

Questions:

1. The public Key in scriptSig is different from the public Key in scriptPubKey?

Yes they are different, pubKeyHash = ripemd160(sha256(pubKey)).

2. How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?

scriptSig is included in the input of the transaction (along with the hash of the previous transaction and the index of the ouput being spent) so that everyone has access to pubKey in order to verify that <sig> is valid against <pubKey>.

3. I have tried to understand the example given on wiki which shows how the script is executed in a stack based manner, but haven't managed.

Well there is not much I could explain differently than any other documentation if you don't provide specifics here.

Simple and less technical explanation for newbies: Let Alice be the sender and Bob be the receiver. Alice creates ScriptPubKey corresponding to private keys of Bob's wallet. She then transmits this ScriptPubKey along with satoshis in the bitcoin network and the satoshis start appearing in the Bob's wallet as balance. So, ScriptPubKey acts like a 'lock'.

Now for Bob to spend those satoshis he must satisfy the conditions Alice placed in the ScriptPubKey. So he creates scriptSig (or signature script) as the solution that satisfies the conditions of ScriptPubKey in order to spend those satoshis. Here, scriptSig acts like keys to ScriptPubKey lock.

Let there be 2 transactions, Transaction A(coinbase) & Transaction B. ScriptPubkey - To lock Transaction A to a Public Key. ScriptSig - Used in Transaction B to unlock Transaction A

Since Transaction A is coinbase (mined by a miner), there will be no ScriptSig. ScriptPubkey of Transaction A is the miner's Public Key script( ie locked to miner's Public Key, so in future he can unlock using his Private Key[ie ScriptSig])

The miner can spend this Bitcoin Transaction to Alice by providing ScriptSig(signed with the miner's Private Key) in the input of Transaction B. Remember Public Key of the miner is generated from his Private Key, it is possible for the Bitcoin program to verify ScriptPubkey of Transaction A from ScriptSig of Transaction B, then if valid the Transaction B will be added to the Blockchain.

The ScriptPubkey of the Transaction B will be the Alice's Public Key, so in future only Alice can spend this Bitcoin using ScriptSig in Transaction C.

I had the same question as well and spent forever trying to understand it and finally cracked it.

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

The key is that sender (A) doesn't need to get the pubKeyHash from "his" Bitcoin Address because it's not relevant. (I also wondered the same thing!)

Think of scriptPubKey happening first. A creates this with B's bitcoin address in place of <pubKeyHash>. That is A's job done. What A has said is "1 BTC now belongs to B but.... only if B can prove that he is the true owner of the bitcoin address that B provided to me". Now take A out of the picture.

B comes along and in his wallet, he sees this 1 BTC amount show up. So technically B "owns" it. But in order for B to spend it, that is send to someone else, B needs to prove that the bitcoin address he gave to A was indeed his. This is where scriptSig comes in. So the <sig> <pubKey> is B's responsibility and B knows all this info anyway.

After reading lots of articles on this, the developer's documentation explains it the best hands down. https://bitcoin.org/en/developer-guide#transactions You just have to read it slowly a few times.

The dev docs also answers your other question of "What is the sig part of scriptSig?"

... data Bob signs includes the txid and output index of the previous transaction, the previous output’s pubkey script, the pubkey script Bob creates which will let the next recipient spend this transaction’s output, and the amount of satoshis to spend to the next recipient.

Please look at the developer's document. It's much clearer. https://bitcoin.org/en/developer-guide#transactions

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.