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

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

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

<p>Think of <strong>scriptPubKey</strong> happening first. A creates this with B's bitcoin address in place of <code>&lt;pubKeyHash&gt;</code>. 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. </p>

<p>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 <strong>scriptSig</strong> comes in. So the <code>&lt;sig&gt; &lt;pubKey&gt;</code> is B's responsibility and B knows all this info anyway.</p>

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

<p>The dev docs also answers your other question of <strong>"What is the sig part of scriptSig?"</strong> </p>

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

CC BY-SA 4.0
2018-10-03T09:01:14.770Z
This answer is less confusing then accepted answer..
Vijay Chavda
CC BY-SA 3.0
2017-01-11T18:40:08.220Z
2017-01-11T18:40:08.220Z
cloudnthings
<p>First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction <strong>A</strong>) and one that spends those funds (Transaction <strong>B</strong>). The <code>scriptPubKey</code> is created by the user that creates Transaction <strong>A</strong>. 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.</p>

<p>This is where Transaction <strong>B</strong> and the <code>scriptSig</code> 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.</p>

<p>The sender of Transaction <strong>A</strong> 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 <a href="https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses">hash of the public key</a>. So the sender now knows all he needs to be able to send the funds to the receiver.</p>

<p>When the receiver wants to spend the funds again he provides the input to the <code>scriptPubKey</code>. As you can see the <code>scriptPubKey</code> 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 <code>OP_CHECKSIG</code> to see whether the input had a valid signature attached.</p>

<p>Take <a href="http://blockchain.info/tx/7da0823ebf7a002a15b6bd11c676c6c213c349c982a9c454539e3ad63e9d57ee">this transaction</a> for example. It claims <a href="http://blockchain.info/tx-index/59229030/0">one output</a>, 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.</p>

CC BY-SA 3.0
2014-07-22T18:16:59.787Z
@cdecker Why is there even any need for the sender in Transaction B to compare the HASH160 of the pubkey to the pubKeyHash? Isn't the signature, which if correct assures that the sender has access to the private key of the address of the output she's sending from, enough to verify she can send from that output? It seems needless to supply the pubkey and verify its hash matches, since the pubkey can be quickly derived from the private key.
almel
CC BY-SA 3.0
2014-07-22T18:43:56.310Z
When funding the sender of Transaction B, the issuer of Transaction A does not know the public key, only it's hash, which is encoded in the address. The creator of Transaction B needs to show the public key, show that it in fact matches the hash in the address and then provide a valid signature using it. If she were not to include the public key and show that it matches the hash, then we are missing an important piece of information, i.e., the public key, and cannot verify the signature.
cdecker
CC BY-SA 3.0
2017-10-04T17:26:05.550Z
i guess in the 2nd paragraph "He creates a new transaction, and adds outputs to it ", it should be "adds inputs to it". User will add inputs to a transaction
lch
CC BY-SA 3.0
2017-10-05T11:09:45.623Z
I tried to avoid introducing inputs at all since they are simply references to previously created outputs, but it might be confusing you're right.
cdecker
CC BY-SA 3.0
2017-11-28T20:43:27.610Z
Might be a little late, but shouldn't the second sentence at the last paragraphe be "It claims one input, by providing .." ?
Arthur Attout
CC BY-SA 3.0
2013-03-09T18:22:32.737Z
2013-03-09T18:22:32.737Z
cdecker
<p>Please look at the developer's document. It's much clearer. <a href="https://bitcoin.org/en/developer-guide#transactions" rel="nofollow">https://bitcoin.org/en/developer-guide#transactions</a></p>

CC BY-SA 3.0
2016-12-14T06:01:17.053Z
I agree, developer document has a clearer explanation.
Vignesh Chandramohan
CC BY-SA 3.0
2015-11-04T08:20:56.590Z
2015-11-04T08:20:56.590Z
jiayaoqijia
<pre><code>scriptSig = &lt;sig&gt; &lt;pubKey&gt;
</code></pre>
<p>What is the sig part of scriptSig?</p>
<p>It is the signature, made by A with his private key, of the content of the transaction he is creating, except for the <code>scriptSig</code> part (to not be recursive). It is made of <code>&lt;hash of the transaction from which an output is being used&gt; &lt;the index of this output in that transaction&gt; &lt;pubKey&gt; &lt;the current transaction output = &lt;scriptPubKey&gt; &lt;1 BTC&gt; &gt;</code>.</p>
<pre><code>sciptPubKey = OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre>
<ol>
<li>The sender (A) only has the Bitcoin Address of the recipient (B), so how does he get the pubKeyHash from his Bitcoin Address?</li>
</ol>
<p>You can find the <code>&lt;pubKeyHash&gt;</code> 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. <code>address = base58_encode(&lt;pubKeyHash&gt; || &lt;padding&gt;)</code>, thus <code>pubKeyHash = base58_decode(address) ^^ &lt;padding&gt;</code>.</p>
<p>Your understanding is on point except for part:</p>
<ol>
<li>Input Script carries information about the &quot;previous transaction&quot; of the sender and points to the appropriate &quot;output&quot; part of &quot;previous transaction&quot; 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).</li>
</ol>
<p>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.</p>
<p>Questions:</p>
<ol>
<li>The public Key in scriptSig is different from the public Key in scriptPubKey?</li>
</ol>
<p>Yes they are different, <code>pubKeyHash = ripemd160(sha256(pubKey))</code>.</p>
<ol start="2">
<li>How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?</li>
</ol>
<p>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 <code>&lt;sig&gt;</code> is valid against <code>&lt;pubKey&gt;</code>.</p>
<ol start="3">
<li>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.</li>
</ol>
<p>Well there is not much I could explain differently than any other documentation if you don't provide specifics here.</p>

CC BY-SA 4.0
2020-04-20T15:41:57.163Z
2020-08-25T15:29:26.113Z
2020-08-25T15:29:26.113Z
user190717
<p><strong>Simple and less technical explanation for newbies:</strong> 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'.</p>

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

CC BY-SA 3.0
2018-01-18T13:26:57.893Z
2018-01-18T13:26:57.893Z
Abhishek Sinha
<p>Let there be 2 transactions, Transaction <strong>A</strong>(coinbase) &amp; Transaction <strong>B</strong>.
<code>ScriptPubkey</code> - To lock Transaction <strong>A</strong> to a Public Key.
<code>ScriptSig</code> - Used in Transaction <strong>B</strong> to unlock Transaction <strong>A</strong></p>

<p>Since Transaction <strong>A</strong> is coinbase (mined by a miner), there will be no <code>ScriptSig</code>. ScriptPubkey of Transaction <strong>A</strong> 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])</p>

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

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

CC BY-SA 3.0
2017-08-15T21:09:36.007Z
2017-08-15T21:09:36.007Z
suhailvs
<p>Scenario: A is sending 1 BTC to B.</p>

<p><strong>scriptSig</strong> appears in the Input Script.</p>

<pre><code>scriptSig = &lt;sig&gt; &lt;pubKey&gt;
</code></pre>

<ol>
<li>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).</li>
</ol>

<p>What is the sig part of scriptSig?</p>

<p><strong>scriptPubKey</strong></p>

<pre><code>scriptPubKey = OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG
</code></pre>

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

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

<p>Now, this is my understanding so far:</p>

<ol>
<li><p>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).</p></li>
<li><p>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.</p></li>
<li><p>Output Script tells us, how many bitcoins the Sender wants to Transfer to the Recipient and it also mentions the Bitcoin Address of recipient.</p></li>
</ol>

<p>Questions:</p>

<ol>
<li><p>The public Key in scriptSig is different from the public Key in scriptPubKey?</p></li>
<li><p>How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?</p></li>
<li><p>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.</p></li>
</ol>

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

<p>Thanks.</p>

CC BY-SA 3.0
2018-02-13T11:37:04.053Z
You can check matt thomas video on youtube, he explains it brilliantly, https://www.youtube.com/watch?v=ir4dDCJhdB4.
Suraj Jain
<transactions><protocol><script><public-key>
What is relation between scriptSig and scriptPubKey?
Neon Flash
# What is relation between scriptSig and scriptPubKey?

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

Scenario: A is sending 1 BTC to B.

**scriptSig** appears in the Input Script.

```
scriptSig = <sig> <pubKey>

```

1. 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 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

```

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

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

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).
2. 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.
3. 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:

1. The public Key in scriptSig is different from the public Key in scriptPubKey?
2. How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?
3. 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.

**Tags:** transactions, protocol, script, public-key

> **Comments:**
> **username_1**: You can check matt thomas video on youtube, he explains it brilliantly, https://www.youtube.com/watch?v=ir4dDCJhdB4.  

---

## 6 answers

### Answer by username_4 on 2013-03-09. Score: 48

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](https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses). 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](http://blockchain.info/tx/7da0823ebf7a002a15b6bd11c676c6c213c349c982a9c454539e3ad63e9d57ee) for example. It claims [one output](http://blockchain.info/tx-index/59229030/0), 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.

> **Comments:**
> **username_5**: @username_4 Why is there even any need for the sender in Transaction B to compare the HASH160 of the pubkey to the pubKeyHash? Isn't the signature, which if correct assures that the sender has access to the private key of the address of the output she's sending from, enough to verify she can send from that output? It seems needless to supply the pubkey and verify its hash matches, since the pubkey can be quickly derived from the private key.  
> **username_4**: When funding the sender of Transaction B, the issuer of Transaction A does not know the public key, only it's hash, which is encoded in the address. The creator of Transaction B needs to show the public key, show that it in fact matches the hash in the address and then provide a valid signature using it. If she were not to include the public key and show that it matches the hash, then we are missing an important piece of information, i.e., the public key, and cannot verify the signature.  
> **username_6**: i guess in the 2nd paragraph "He creates a new transaction, and adds outputs to it ", it should be "adds inputs to it". User will add inputs to a transaction  
> **username_4**: I tried to avoid introducing inputs at all since they are simply references to previously created outputs, but it might be confusing you're right.  
> **username_7**: Might be a little late, but shouldn't the second sentence at the last paragraphe be "It claims one input, by providing .." ?  

---

### Answer by username_2 on 2017-01-11. Score: 12

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.

> **Comments:**
> **username_3**: This answer is less confusing then accepted answer..  

---

### Answer by username_8 on 2015-11-04. Score: 3

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

> **Comments:**
> **username_9**: I agree, developer document has a clearer explanation.  

---

### Answer by username_10 on 2020-04-20. Score: 1

```
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.


---

### Answer by username_11 on 2018-01-18. Score: -1

**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.


---

### Answer by username_12 on 2017-08-15. Score: -1

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.


---

