<p>AFAIK this was a design choice by Satoshi originally that is unnecessary for the reasons stated in the OP. There is a comment about <a href="https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/Transaction.java#L1034" rel="nofollow noreferrer">this in bitcoinj</a></p>

<pre><code>  // Set the input to the script of its output. Bitcoin Core does this but the step has no obvious purpose as
  // the signature covers the hash of the prevout transaction which obviously includes the output script
  // already. Perhaps it felt safer to him in some way, or is another leftover from how the code was written.
</code></pre>

<p>However, it should be noted that there is value in signing particular parts of the previous transaction. Segwit just implemented a new transaction signature algorithm to the cover the amount of satoshis a input is spending from a given output. </p>

CC BY-SA 3.0
2016-11-29T16:28:29.723Z
2016-11-29T16:28:29.723Z
Chris Stewart
<p>The signature should cover as much data, as possible. </p>

<p>And it is bad idea to sign the same data for all input scripts if the transaction redeems several outputs from one transaction</p>

CC BY-SA 3.0
2016-11-29T13:03:52.177Z
2016-11-29T13:23:51.783Z
2016-11-29T13:23:51.783Z
amaclin
<p>I was checking OP_CHECKSIG today and see that the signature of a transaction will be computed from the transaction but copying the ScriptPubKey from the transaction referenced as input into the SigKey of the new transaction.</p>

<p>I guess this has something to do with tx malleability, but I cannot see in what case this would really help? The tx-inputs already reference IDs that can be changed implying malleability. </p>

<p>It would only make sense to include the inputs ScriptPubKeys if it would be possible to keep an ID while changing its ScriptPubKey (which is not possible), or am I missing something?</p>

<p>I am refering to this graphic Step 7 + 8:
<a href="https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png" rel="nofollow">https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png</a></p>

<transactions><signature><checksig>
(CHECKSIG) Why is the ScriptPubKey from tx-inputs part of the signature?
Bjarne Magnussen
# (CHECKSIG) Why is the ScriptPubKey from tx-inputs part of the signature?

(Asked by: username_0 on 2015-09-17)

I was checking OP\_CHECKSIG today and see that the signature of a transaction will be computed from the transaction but copying the ScriptPubKey from the transaction referenced as input into the SigKey of the new transaction.

I guess this has something to do with tx malleability, but I cannot see in what case this would really help? The tx-inputs already reference IDs that can be changed implying malleability.

It would only make sense to include the inputs ScriptPubKeys if it would be possible to keep an ID while changing its ScriptPubKey (which is not possible), or am I missing something?

I am refering to this graphic Step 7 + 8:
<https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png>

**Tags:** transactions, signature, checksig


---

## 2 answers

### Answer by username_1 on 2016-11-29. Score: 3 | Accepted answer

AFAIK this was a design choice by Satoshi originally that is unnecessary for the reasons stated in the OP. There is a comment about [this in bitcoinj](https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/Transaction.java#L1034)

```
  // Set the input to the script of its output. Bitcoin Core does this but the step has no obvious purpose as
  // the signature covers the hash of the prevout transaction which obviously includes the output script
  // already. Perhaps it felt safer to him in some way, or is another leftover from how the code was written.

```

However, it should be noted that there is value in signing particular parts of the previous transaction. Segwit just implemented a new transaction signature algorithm to the cover the amount of satoshis a input is spending from a given output.


---

### Answer by username_2 on 2016-11-29. Score: 0

The signature should cover as much data, as possible.

And it is bad idea to sign the same data for all input scripts if the transaction redeems several outputs from one transaction


---

