<p>I think, since with some sighash types, the scriptPubKey is not part of the txid. So it is not automatically taken into consideration when the txid is already part of the hash.</p>

CC BY-SA 3.0
2016-08-07T18:12:32.580Z
2016-08-07T18:12:32.580Z
Steven Roose
<p>I've closely studied the deservedly famous OP_CHECKSIG explanation found <a href="https://en.bitcoin.it/wiki/OP_CHECKSIG">here</a>, including the diagram found <a href="https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png">here</a>. That explanation details how to construct the message that is signed via ECDSA, producing the digital signature for SigScript. All good.</p>

<p>By way of summary, the aforementioned message is an amalgamation of the new transaction under construction (with its ScriptSigs nulled out) <em>and</em> the scriptPubKey from the sourcing transaction output. For clarity, the "sourcing transaction output" is the one identified in the transaction input under construction by its Transaction Hash field and its Output Index field. All good.</p>

<p>MY QUESTION: in the new transaction under construction, its Transaction Hash field already "fingerprints" the sourcing transaction output. <strong>Why go to the effort of inserting the aforementioned scriptPubKey from the sourcing transaction output into the message?</strong> That seems redundant, given that the hash digest in the Transaction Hash field fingerprints the entire sourcing transaction.</p>

<p>I ask this question in order to more thoroughly understand the logic behind the intricate construction of the message that is signed via ECDSA.</p>

<message-signing>
OP_CHECKSIG: reasoning behind construction of message to be signed
Pressed250
# OP_CHECKSIG: reasoning behind construction of message to be signed

(Asked by: username_0 on 2016-08-05)

I've closely studied the deservedly famous OP\_CHECKSIG explanation found [here](https://en.bitcoin.it/wiki/OP_CHECKSIG), including the diagram found [here](https://en.bitcoin.it/wiki/File:Bitcoin_OpCheckSig_InDetail.png). That explanation details how to construct the message that is signed via ECDSA, producing the digital signature for SigScript. All good.

By way of summary, the aforementioned message is an amalgamation of the new transaction under construction (with its ScriptSigs nulled out) *and* the scriptPubKey from the sourcing transaction output. For clarity, the "sourcing transaction output" is the one identified in the transaction input under construction by its Transaction Hash field and its Output Index field. All good.

MY QUESTION: in the new transaction under construction, its Transaction Hash field already "fingerprints" the sourcing transaction output. **Why go to the effort of inserting the aforementioned scriptPubKey from the sourcing transaction output into the message?** That seems redundant, given that the hash digest in the Transaction Hash field fingerprints the entire sourcing transaction.

I ask this question in order to more thoroughly understand the logic behind the intricate construction of the message that is signed via ECDSA.

**Tags:** message-signing


---

## 1 answers

### Answer by username_1 on 2016-08-07. Score: 1

I think, since with some sighash types, the scriptPubKey is not part of the txid. So it is not automatically taken into consideration when the txid is already part of the hash.


---

