<p><code>witnessScript</code> is not the <code>redeemScript</code> but it is analog to it. It is the actual Script that is committed to by its hash in the output, and executed when spending it. It is the &quot;Segwit version of the <code>redeemScript</code>&quot; if you will.</p>
<p><code>CODESEPARATOR</code> is an (interesting [<strong>1</strong>]) OP code which allows to customize the behaviour of the <code>CHECKSIG</code> OP code. It allows to section the script code for a signature to commit to only part of it.<br />
BIP143 <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#specification" rel="nofollow noreferrer">slightly</a> <a href="https://github.com/bitcoin/bitcoin/blob/88d8b4e182bfc75e8496f7046af7aab93307b9d0/src/script/interpreter.cpp#L355" rel="nofollow noreferrer">changed</a> its behaviour for SegWit scripts.</p>
<p>Regarding your last question, if i understand correctly you are refering to these comments in the test vector.</p>
<blockquote>
<pre><code>(please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
</code></pre>
</blockquote>
<blockquote>
<pre><code>everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed
</code></pre>
</blockquote>
<p>These comments are here to illustrate the new behaviour introduced in BIP143. The witness script of the output these signatures are for is the following.</p>
<pre><code>&lt;026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae&gt; CHECKSIGVERIFY CODESEPARATOR &lt;0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465&gt; CHECKSIG
</code></pre>
<p>The two comments describe the difference in the <code>scriptCode</code> for computing the signature of each public key contained in the witness script.<br />
For the first one there was no <code>CODESEPARATOR</code> before the <code>CHECKSIGVERIFY</code>, therefore the <code>scriptCode</code> is the entire witness Script. For the second one however there was a <code>CODESEPARATOR</code> executed before the <code>CHECKSIG</code>, therefore the <code>scriptCode</code> is the part of the witness script starting just after the <code>CODESEPARATOR</code> up to the end.</p>
<hr />
<p>[<strong>1</strong>] <code>CODESEPARATOR</code> was initially used to execute the scriptPubkey and scriptSig as a single stack (inserted in-between). It was then removed by Satoshi when patching <a href="https://bitcoin.stackexchange.com/q/38037/101498">the <code>1 RETURN</code> bug</a>.</p>

CC BY-SA 4.0
2020-05-10T11:02:56.243Z
2022-10-03T10:18:05.577Z
2022-10-03T10:18:05.577Z
Antoine Poinsot
<p>Yes, witnessScript is just the RedeemScript, which would also be the last element of the witness data.  I am not sure about the OP_CODESEPARATOR, or why a script would contain that in the first place.</p>

CC BY-SA 4.0
2019-08-14T01:37:03.813Z
2019-08-14T01:37:03.813Z
user1055568
<p>I read the bip143, but didn't understand how to calculate the scriptCode of p2wsh.</p>
<p>bip143 told us:</p>
<pre><code>A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program
Double SHA256 of the serialization of:
  1. nVersion of the transaction (4-byte little endian)
  2. hashPrevouts (32-byte hash)
  3. hashSequence (32-byte hash)
  4. outpoint (32-byte hash + 4-byte little endian) 
  5. scriptCode of the input (serialized as scripts inside CTxOuts)
  6. value of the output spent by this input (8-byte little endian)
  7. nSequence of the input (4-byte little endian)
  8. hashOutputs (32-byte hash)
  9. nLocktime of the transaction (4-byte little endian)
  10. sighash type of the signature (4-byte little endian)


The item 5:

For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
For P2WSH witness program,
if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)
</code></pre>
<p>I don't know how to find out if &quot;the signature checking opcode being executed&quot;.
Then I read the example &quot;Native P2WSH&quot; in bip143 and I am even more confused.</p>
<p>Here is the first example of &quot;Native P2WSH&quot;:</p>
<pre><code>The following is an unsigned transaction: 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000
  
    nVersion:  01000000
    txin:      02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
                  0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
    txout:     01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
    nLockTime: 00000000
  
  The first input comes from an ordinary P2PK:
    scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
    private key:  b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
    signature:    304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
  
  The second input comes from a native P2WSH witness program:
    scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
    witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                   &lt;026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae&gt; CHECKSIGVERIFY CODESEPARATOR &lt;0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465&gt; CHECKSIG
  
  To sign it with a nHashType of 3 (SIGHASH_SINGLE):
  
  hashPrevouts:
    dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
  = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
  
    nVersion:     01000000
    hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
    hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
    outpoint:     0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000
    scriptCode:   (see below)
    amount:       0011102401000000
    nSequence:    ffffffff
    hashOutputs:  0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
    nLockTime:    00000000
    nHashType:    03000000
  
  scriptCode:  4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                                                                                       ^^
               (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
  preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
  sigHash:     82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391
  public key:  026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
  private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
  signature:   3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
  
  scriptCode:  23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
  preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
  sigHash:     fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47
  public key:  0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
  private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
  signature:   304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
  
  The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000

01000000
0001
02
fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000
48
47304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201
ffffffff
0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 0000000000
ffffffff

01
00f2052a01000000
1976a914a30741f8145e5acadf23f751864167f32e0963f788ac

0003

47304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
</code></pre>
<p>So here are my questions:</p>
<ol>
<li>Here &quot;witnessScript&quot; is RedeemScript, right?</li>
<li>What is meaning of 'CODESEPARATOR' here?</li>
<li>Why calculate both scriptCode(OP_CODESEPARATOR is not removed &amp;&amp; OP_CODESEPARATOR is removed) and both put them into witness data?</li>
</ol>

<script><segregated-witness><signature><p2wsh><opcodes>
How to calculate P2WSH signatures with OP_CODESEPARATOR?
jumper
# How to calculate P2WSH signatures with OP_CODESEPARATOR?

(Asked by: username_0 on 2019-07-29)

I read the bip143, but didn't understand how to calculate the scriptCode of p2wsh.

bip143 told us:

```
A new transaction digest algorithm is defined, but only applicable to sigops in version 0 witness program
Double SHA256 of the serialization of:
  1. nVersion of the transaction (4-byte little endian)
  2. hashPrevouts (32-byte hash)
  3. hashSequence (32-byte hash)
  4. outpoint (32-byte hash + 4-byte little endian) 
  5. scriptCode of the input (serialized as scripts inside CTxOuts)
  6. value of the output spent by this input (8-byte little endian)
  7. nSequence of the input (4-byte little endian)
  8. hashOutputs (32-byte hash)
  9. nLocktime of the transaction (4-byte little endian)
  10. sighash type of the signature (4-byte little endian)

The item 5:

For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac.
For P2WSH witness program,
if the witnessScript does not contain any OP_CODESEPARATOR, the scriptCode is the witnessScript serialized as scripts inside CTxOut.
if the witnessScript contains any OP_CODESEPARATOR, the scriptCode is the witnessScript but removing everything up to and including the last executed OP_CODESEPARATOR before the signature checking opcode being executed, serialized as scripts inside CTxOut. (The exact semantics is demonstrated in the examples below)

```

I don't know how to find out if "the signature checking opcode being executed".
Then I read the example "Native P2WSH" in bip143 and I am even more confused.

Here is the first example of "Native P2WSH":

```
The following is an unsigned transaction: 0100000002fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e0000000000ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac00000000
  
    nVersion:  01000000
    txin:      02 fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000 00 ffffffff
                  0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 00000000 00 ffffffff
    txout:     01 00f2052a01000000 1976a914a30741f8145e5acadf23f751864167f32e0963f788ac
    nLockTime: 00000000
  
  The first input comes from an ordinary P2PK:
    scriptPubKey: 21036d5c20fa14fb2f635474c1dc4ef5909d4568e5569b79fc94d3448486e14685f8ac value: 1.5625
    private key:  b8f28a772fccbf9b4f58a4f027e07dc2e35e7cd80529975e292ea34f84c4580c
    signature:    304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201 (SIGHASH_ALL)
  
  The second input comes from a native P2WSH witness program:
    scriptPubKey : 00205d1b56b63d714eebe542309525f484b7e9d6f686b3781b6f61ef925d66d6f6a0, value: 49
    witnessScript: 21026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                   <026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG
  
  To sign it with a nHashType of 3 (SIGHASH_SINGLE):
  
  hashPrevouts:
    dSHA256(fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000)
  = ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
  
    nVersion:     01000000
    hashPrevouts: ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d41
    hashSequence: 0000000000000000000000000000000000000000000000000000000000000000
    outpoint:     0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f800000000
    scriptCode:   (see below)
    amount:       0011102401000000
    nSequence:    ffffffff
    hashOutputs:  0000000000000000000000000000000000000000000000000000000000000000 (this is the second input but there is only one output)
    nLockTime:    00000000
    nHashType:    03000000
  
  scriptCode:  4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
                                                                                       ^^
               (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
  preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8000000004721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
  sigHash:     82dde6e4f1e94d02c2b7ad03d2115d691f48d064e9d52f58194a6637e4194391
  public key:  026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae
  private key: 8e02b539b1500aa7c81cf3fed177448a546f19d2be416c0c61ff28e577d8d0cd
  signature:   3044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
  
  scriptCode:  23210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac
               (everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed)
  preimage:    01000000ef546acf4a020de3898d1b8956176bb507e6211b5ed3619cd08b6ea7e2a09d4100000000000000000000000000000000000000000000000000000000000000000815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000023210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac0011102401000000ffffffff00000000000000000000000000000000000000000000000000000000000000000000000003000000
  sigHash:     fef7bd749cce710c5c052bd796df1af0d935e59cea63736268bcbe2d2134fc47
  public key:  0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465
  private key: 86bf2ed75935a0cbef03b89d72034bb4c189d381037a5ac121a70016db8896ec
  signature:   304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
  
  The serialized signed transaction is: 01000000000102fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e000000004847304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201ffffffff0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f80000000000ffffffff0100f2052a010000001976a914a30741f8145e5acadf23f751864167f32e0963f788ac000347304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e27034721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac00000000

01000000
0001
02
fe3dc9208094f3ffd12645477b3dc56f60ec4fa8e6f5d67c565d1c6b9216b36e 00000000
48
47304402200af4e47c9b9629dbecc21f73af989bdaa911f7e6f6c2e9394588a3aa68f81e9902204f3fcf6ade7e5abb1295b6774c8e0abd94ae62217367096bc02ee5e435b67da201
ffffffff
0815cf020f013ed6cf91d29f4202e8a58726b1ac6c79da47c23d1bee0a6925f8 0000000000
ffffffff

01
00f2052a01000000
1976a914a30741f8145e5acadf23f751864167f32e0963f788ac

0003

47304402200de66acf4527789bfda55fc5459e214fa6083f936b430a762c629656216805ac0220396f550692cd347171cbc1ef1f51e15282e837bb2b30860dc77c8f78bc8501e503
473044022027dc95ad6b740fe5129e7e62a75dd00f291a2aeb1200b84b09d9e3789406b6c002201a9ecd315dd6a0e632ab20bbb98948bc0c6fb204f2c286963bb48517a7058e2703
4721026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880aeadab210255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465ac

```

So here are my questions:

1. Here "witnessScript" is RedeemScript, right?
2. What is meaning of 'CODESEPARATOR' here?
3. Why calculate both scriptCode(OP\_CODESEPARATOR is not removed && OP\_CODESEPARATOR is removed) and both put them into witness data?

**Tags:** script, segregated-witness, signature, p2wsh, opcodes


---

## 2 answers

### Answer by username_1 on 2020-05-10. Score: 0

`witnessScript` is not the `redeemScript` but it is analog to it. It is the actual Script that is committed to by its hash in the output, and executed when spending it. It is the "Segwit version of the `redeemScript`" if you will.

`CODESEPARATOR` is an (interesting [**1**]) OP code which allows to customize the behaviour of the `CHECKSIG` OP code. It allows to section the script code for a signature to commit to only part of it.  
BIP143 [slightly](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#specification) [changed](https://github.com/bitcoin/bitcoin/blob/88d8b4e182bfc75e8496f7046af7aab93307b9d0/src/script/interpreter.cpp#L355) its behaviour for SegWit scripts.

Regarding your last question, if i understand correctly you are refering to these comments in the test vector.

> ```
> (please note that the not-yet-executed OP_CODESEPARATOR is not removed from the scriptCode)
>
> ```

> ```
> everything up to the last executed OP_CODESEPARATOR, including that OP_CODESEPARATOR, are removed
>
> ```

These comments are here to illustrate the new behaviour introduced in BIP143. The witness script of the output these signatures are for is the following.

```
<026dccc749adc2a9d0d89497ac511f760f45c47dc5ed9cf352a58ac706453880ae> CHECKSIGVERIFY CODESEPARATOR <0255a9626aebf5e29c0e6538428ba0d1dcf6ca98ffdf086aa8ced5e0d0215ea465> CHECKSIG

```

The two comments describe the difference in the `scriptCode` for computing the signature of each public key contained in the witness script.  
For the first one there was no `CODESEPARATOR` before the `CHECKSIGVERIFY`, therefore the `scriptCode` is the entire witness Script. For the second one however there was a `CODESEPARATOR` executed before the `CHECKSIG`, therefore the `scriptCode` is the part of the witness script starting just after the `CODESEPARATOR` up to the end.

---

[**1**] `CODESEPARATOR` was initially used to execute the scriptPubkey and scriptSig as a single stack (inserted in-between). It was then removed by Satoshi when patching [the `1 RETURN` bug](https://bitcoin.stackexchange.com/q/38037/101498).


---

### Answer by username_2 on 2019-08-14. Score: -1

Yes, witnessScript is just the RedeemScript, which would also be the last element of the witness data. I am not sure about the OP\_CODESEPARATOR, or why a script would contain that in the first place.


---

