<blockquote>
  <p>But how the script interpreter knows the sig the signature of the
  previous transition hash, what if the sig is the signature of some
  other content?</p>
</blockquote>

<p>It also compares the signed data with the transaction hash itself. In general, this is how digital signatures work. If the data isn't <strong><em>signed by the right key</em></strong>, and <strong><em>data hash doesn't match</em></strong>, then the signature is invalid. See <a href="https://github.com/bitcoin/bitcoin/blob/v0.16.2/src/script/interpreter.cpp#L1264" rel="nofollow noreferrer">src/script/interpreter.cpp L#1264</a>.</p>

<p><strong>This verification process ensures two things:</strong><br>
1. The person has the private key which corresponds with the public key provided.<br>
2. The data has not been tampered with.</p>

CC BY-SA 4.0
2018-08-31T15:22:13.297Z
The code in SignatureHash() looks reconstruct (l1217~1235) part of the transaction and hash again. Then use pubKey to verify the hash and sig. 
Is the "data" you mentioned above is that the reconstructed byte list?
Carpemer
CC BY-SA 4.0
2018-08-31T17:15:37.960Z
It's actually not simple, but there is a good explanation of what is hashed and signed here: https://bitcoin.stackexchange.com/a/5241/60443
JBaczuk
CC BY-SA 4.0
2018-09-01T02:26:49.307Z
One more question, in step 9, why the sender will decide the fee (0.001) in the process of generation input. If it is true, how the verifier could know what is the fee from the hash code? Actually, from the code in GitHub, it looks like it uses the original amount directly, and in the gitbub, it output the amount and then sequence (FFFFFFFF), but in that post, the order like amount first, then output script in step 9 and step 10.
Carpemer
CC BY-SA 4.0
2018-08-30T13:08:13.773Z
2018-08-30T13:36:15.613Z
2018-08-30T13:36:15.613Z
JBaczuk
<p><a href="https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29" rel="nofollow noreferrer">https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29</a></p>

<p>The last step of pay to pubkey hash transaction is to check the signature of the previous transaction tx hash  and pubkey .</p>

<p>But how the script interpreter knows the sig is the signature of the previous transition hash, what if the sig is the signature of some other content?</p>

<transactions><script><signature>
How OP_CHECKSIG knows the source of sig in pay to pubkey hash transaction
Carpemer
# How OP_CHECKSIG knows the source of sig in pay to pubkey hash transaction

(Asked by: username_0 on 2018-08-30)

<https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bitcoin_address_.28pay-to-pubkey-hash.29>

The last step of pay to pubkey hash transaction is to check the signature of the previous transaction tx hash and pubkey .

But how the script interpreter knows the sig is the signature of the previous transition hash, what if the sig is the signature of some other content?

**Tags:** transactions, script, signature


---

## 1 answers

### Answer by username_1 on 2018-08-30. Score: 2 | Accepted answer

> But how the script interpreter knows the sig the signature of the
> previous transition hash, what if the sig is the signature of some
> other content?

It also compares the signed data with the transaction hash itself. In general, this is how digital signatures work. If the data isn't ***signed by the right key***, and ***data hash doesn't match***, then the signature is invalid. See [src/script/interpreter.cpp L#1264](https://github.com/bitcoin/bitcoin/blob/v0.16.2/src/script/interpreter.cpp#L1264).

**This verification process ensures two things:**  
1. The person has the private key which corresponds with the public key provided.  
2. The data has not been tampered with.

> **Comments:**
> **username_0**: The code in SignatureHash() looks reconstruct (l1217~1235) part of the transaction and hash again. Then use pubKey to verify the hash and sig.  Is the "data" you mentioned above is that the reconstructed byte list?  
> **username_1**: It's actually not simple, but there is a good explanation of what is hashed and signed here: https://bitcoin.stackexchange.com/a/5241/60443  
> **username_0**: One more question, in step 9, why the sender will decide the fee (0.001) in the process of generation input. If it is true, how the verifier could know what is the fee from the hash code? Actually, from the code in GitHub, it looks like it uses the original amount directly, and in the gitbub, it output the amount and then sequence (FFFFFFFF), but in that post, the order like amount first, then output script in step 9 and step 10.  

---

