<p>Any data that is included in the sighash must be revealed to the signer. It also means that the signature itself directly commits to that information and so must be truthfully provided to the signer as otherwise an invalid signature would be created.</p>
<p>By including the scriptPubKey or the redeemScript, we ensure that the signers are aware of the script that their signature will be involved in. This removes a class of potential attacks where the signer is lied to about the script that is involved in that input. It may be that the signer does not want to sign for certain scripts, and so having the script be part of the signature means that the signer will always know what script it signed for.</p>

CC BY-SA 4.0
2022-07-22T15:46:39.513Z
As long as the prevout is committed to, it's just a shortcut though: the Script is already indirectly committed to?
Antoine Poinsot
CC BY-SA 4.0
2022-07-22T15:56:56.337Z
@AntoinePoinsot The point isn't commitment (which is indeed true regardless of whether this replacement happens), but making it cheap for signers make sure their information is correct (without it, signers would need to be given the full transactions creating the outputs to know the scriptPubKeys being spent). Of course, as we now know, the substitution in legacy sighashing isn't sufficient, and even the segwit one (which includes more information directly) isn't.
Pieter Wuille
CC BY-SA 4.0
2022-07-22T15:31:41.997Z
2022-07-22T15:31:41.997Z
Ava Chow
<p>I'm reading <a href="https://github.com/jimmysong/programmingbitcoin" rel="nofollow noreferrer">Programming Bitcoin</a>. And in Chapter7, the author talked about the way how signature hash is calculated by replacing the transaction's ScriptSig with the corresponding previous ScriptPubKey. I understand that we can't calculate the signature of a transaction with the signature inside it. But why not just drop the ScriptSig part instead of replace it with the previous ScriptPubKey? And by the way, the same confusion arise on me with the p2sh , where the ScriptSig is replaced with the corresponding RedeemScript.</p>

<signature><input-script><programming-bitcoin-book>
Why we need to repalce the ScriptSig with the previous ScriptPubKey when calculate the per input signature hash?
Shawn C
# Why we need to repalce the ScriptSig with the previous ScriptPubKey when calculate the per input signature hash?

(Asked by: username_0 on 2022-07-22)

I'm reading [Programming Bitcoin](https://github.com/jimmysong/programmingbitcoin). And in Chapter7, the author talked about the way how signature hash is calculated by replacing the transaction's ScriptSig with the corresponding previous ScriptPubKey. I understand that we can't calculate the signature of a transaction with the signature inside it. But why not just drop the ScriptSig part instead of replace it with the previous ScriptPubKey? And by the way, the same confusion arise on me with the p2sh , where the ScriptSig is replaced with the corresponding RedeemScript.

**Tags:** signature, input-script, programming-bitcoin-book


---

## 1 answers

### Answer by username_1 on 2022-07-22. Score: 4 | Accepted answer

Any data that is included in the sighash must be revealed to the signer. It also means that the signature itself directly commits to that information and so must be truthfully provided to the signer as otherwise an invalid signature would be created.

By including the scriptPubKey or the redeemScript, we ensure that the signers are aware of the script that their signature will be involved in. This removes a class of potential attacks where the signer is lied to about the script that is involved in that input. It may be that the signer does not want to sign for certain scripts, and so having the script be part of the signature means that the signer will always know what script it signed for.

> **Comments:**
> **username_2**: As long as the prevout is committed to, it's just a shortcut though: the Script is already indirectly committed to?  
> **username_3**: @username_2 The point isn't commitment (which is indeed true regardless of whether this replacement happens), but making it cheap for signers make sure their information is correct (without it, signers would need to be given the full transactions creating the outputs to know the scriptPubKeys being spent). Of course, as we now know, the substitution in legacy sighashing isn't sufficient, and even the segwit one (which includes more information directly) isn't.  

---

