<p>As noted in BIP 143, the <code>CODESEPARATOR</code> opcode operates by truncating the <code>scriptCode</code> value that is included in the digest.  While rarely used, <code>CODESEPARATOR</code> does provide a method to create signatures that are bound to specific code paths taken by Script, even when the same pubkey key used for redeeming the UTXO.</p>

<p>If the <code>scriptCode</code> were removed from the digest then <code>CODESEPARATOR</code> wouldn't work, unless we added back in support for it in some other way.</p>

CC BY-SA 4.0
2019-10-09T20:31:57.067Z
2019-10-09T20:31:57.067Z
Russell O'Connor
<blockquote>
  <p>What problems could arise if the scriptCode of the input were not included in the digest?</p>
</blockquote>

<p>Almost certainly nothing.</p>

<p>The reason for doing this is a very intentional design choice to limit the number of changes SegWit makes. Given that it has script versioning, it would be easy to introduce different sighashing schemes later if desired, we had the option of only making intended changes, as opposed to redesigning it from scratch. The intentional changes to the sighash algorithm are:</p>

<ul>
<li>Use shared precomputed per-transaction hashes to avoid O(n^2)</li>
<li>Commit to amounts spent</li>
</ul>

<p>So the hash structure remains the same, and contains all the same data. The sighash flags still have the same effect. The only thing that changes in BIP143 is that some data is now organized under precomputed hashes, and the input amounts go into it. Everything else is the same, which includes a commitment to the scriptCode - even though there is no good reason for that anymore.</p>

<p>EDIT: Do see Russell O'Connor's answer below for a minor use case.</p>

CC BY-SA 4.0
2019-09-19T15:18:20.857Z
Was there ever a good reason to include the scriptCode in the blob for signing (in legacy transactions)? It seems redundant given the outpoint is specified and signed.
pinhead
CC BY-SA 4.0
2017-05-18T18:14:51.343Z
2019-10-09T20:33:02.857Z
2019-10-09T20:33:02.857Z
Pieter Wuille
<p>BIP143 <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Specification" rel="noreferrer">specifies "a new transaction digest algorithm"</a>.</p>

<blockquote>
  <ol start="5">
  <li>scriptCode of the input (serialized as scripts inside CTxOuts)</li>
  </ol>
</blockquote>

<p>What problems could arise if the <code>scriptCode of the input</code> were not included in the digest?</p>

<script><segregated-witness><transaction-input>
What is the point of including the scriptCode of the input in the transaction digest of segwit?
Murch
# What is the point of including the scriptCode of the input in the transaction digest of segwit?

(Asked by: username_0 on 2017-05-18)

BIP143 [specifies "a new transaction digest algorithm"](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Specification).

> 5. scriptCode of the input (serialized as scripts inside CTxOuts)

What problems could arise if the `scriptCode of the input` were not included in the digest?

**Tags:** script, segregated-witness, transaction-input


---

## 2 answers

### Answer by username_2 on 2017-05-18. Score: 4 | Accepted answer

> What problems could arise if the scriptCode of the input were not included in the digest?

Almost certainly nothing.

The reason for doing this is a very intentional design choice to limit the number of changes SegWit makes. Given that it has script versioning, it would be easy to introduce different sighashing schemes later if desired, we had the option of only making intended changes, as opposed to redesigning it from scratch. The intentional changes to the sighash algorithm are:

* Use shared precomputed per-transaction hashes to avoid O(n^2)
* Commit to amounts spent

So the hash structure remains the same, and contains all the same data. The sighash flags still have the same effect. The only thing that changes in BIP143 is that some data is now organized under precomputed hashes, and the input amounts go into it. Everything else is the same, which includes a commitment to the scriptCode - even though there is no good reason for that anymore.

EDIT: Do see username_1 username_1's answer below for a minor use case.

> **Comments:**
> **username_3**: Was there ever a good reason to include the scriptCode in the blob for signing (in legacy transactions)? It seems redundant given the outpoint is specified and signed.  

---

### Answer by username_1 on 2019-10-09. Score: 2

As noted in BIP 143, the `CODESEPARATOR` opcode operates by truncating the `scriptCode` value that is included in the digest. While rarely used, `CODESEPARATOR` does provide a method to create signatures that are bound to specific code paths taken by Script, even when the same pubkey key used for redeeming the UTXO.

If the `scriptCode` were removed from the digest then `CODESEPARATOR` wouldn't work, unless we added back in support for it in some other way.


---

