segregated witness – Why are P2WSH addresses larger than P2SH addresses?

Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they’re slightly longer for the same amount of data, but are case insensitive instead.

For any kind of “multi party” address (that is, an address constructed by multiple distinct and distrusting participants that each have their own key, such as multisig), a particular collision attack exists that has runtime O(2bits/2), where bits is the number of bits of entropy in the address.

P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an ~280 attack is possible(*). Bitcoin typically has a 2128 security target for attacks, so this is insufficient. That doesn’t mean such a collision attack is practical – it’s just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.

To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has ~2128 collision security.

In the upcoming Taproot upgrade, a new P2TR address type is introduced. It has the same length as P2WSH addresses, and also contains ~256 bits of entropy. Due to the nature of Taproot, which merges P2PKH and P2SH style spending into one, this means even single-party addresses are 256 bits in it.

For details of the attack, see https://bitcoin.stackexchange.com/a/54847/208.

(*) There are ways to avoid the collision attack problem, even with short hashes. They significantly complicate address construction and spending however. So the choice to provide a 256-bit script hash mechanism is really just to make sure multi-party address construction isn’t needlessly complicated.

bitcoin core – Verifying a P2WSH by hand

To test my understanding of the signing and verifying process i tried to verify some random Bitcoin transactions by hand. Sadly i got stuck with a P2WSH transaction, i choose the following transaction with Hash c53b99c9fdba60fd47c6026177d3f6e1ed6d3abde8f433364619aa7d437dad26

With the raw transaction:

010000000001012198e5bc0860a4fcf420e2b909fce47e746357457b060c63571e12bd84fec4a70100000000ffffffff0220120a000000000017a91417b9a9afddaae527d25788bce2202563d4ab0d058784ea110000000000220020701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d0400473044022014cd600863ad3c9f6802383fe814a693a77144117cf7694f63b558b8c02d801c02201c3ad9901f659742668caf770f3d7f89a3633f9ccd2bfdd6a7c6f7529fe7b43101473044022047e4ad9788da6b764e723dd71d9fe07a217e48871129a672ef2788eb0d331a7a02206107b10c23e8720df9f1e5f609c471726066c5b72c56ee774615498f8fe62e8d016952210375e00eb72e29da82b89367947f29ef34afb75e8654f6ea368e0acdfd92976b7c2103a1b26313f430c4b15bb1fdce663207659d8cac749a0e53d70eff01874496feff2103c96d495bfdd5ba4145e3e046fee45e84a8a48ad05bd8dbb395c011a32cf9f88053ae00000000

I can deserialize this to:


TX version number = 00000001
Inputs count = 01
TX from hash = a7c4fe84bd121e57630c067b455763747ee4fc09b9e220f4fca46008bce59821
TX outpoint Index = 00000001
Input script =
Sequence number = ffffffff
Outputs count = 02
Value(base 10) = 660000
Output script = a91417b9a9afddaae527d25788bce2202563d4ab0d0587
Value(base 10) = 1174148
Output script = 0020701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d
Witness 0 0 = 00
Witness 0 1 = 473044022014cd600863ad3c9f6802383fe814a693a77144117cf7694f63b558b8c02d801c02201c3ad9901f659742668caf770f3d7f89a3633f9ccd2bfdd6a7c6f7529fe7b43101
Witness 0 2 = 473044022047e4ad9788da6b764e723dd71d9fe07a217e48871129a672ef2788eb0d331a7a02206107b10c23e8720df9f1e5f609c471726066c5b72c56ee774615498f8fe62e8d01
Witness 0 3 = 6952210375e00eb72e29da82b89367947f29ef34afb75e8654f6ea368e0acdfd92976b7c2103a1b26313f430c4b15bb1fdce663207659d8cac749a0e53d70eff01874496feff2103c96d495bfdd5ba4145e3e046fee45e84a8a48ad05bd8dbb395c011a32cf9f88053ae
Lock time = 00000000


Now i try to compute the MessageHash that gets signed:

with:
hashPrevouts = sha256²(2198e5bc0860a4fcf420e2b909fce47e746357457b060c63571e12bd84fec4a701000000)
hashSequence = sha256²(ffffffff)
hashOutputs = sha256²(20120a0000000000a91417b9a9afddaae527d25788bce2202563d4ab0d058784ea1100000000000020701a8d401c84fb13e6baf169d59684e17abd9fa216c8cc5b9fc63d622ff8c58d)

Version: 01000000
hashPrevouts: 65aa319c96c046e8589c758adf7441d335682d3fc76df649180c4f94a1c4a731
hashSequence: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
outPoint: 2198e5bc0860a4fcf420e2b909fce47e746357457b060c63571e12bd84fec4a701000000
scriptCode: 6952210375e00eb72e29da82b89367947f29ef34afb75e8654f6ea368e0acdfd92976b7c2103a1b26313f430c4b15bb1fdce663207659d8cac749a0e53d70eff01874496feff2103c96d495bfdd5ba4145e3e046fee45e84a8a48ad05bd8dbb395c011a32cf9f88053ae
value: 345c1d0000000000
nSequence: ffffffff
hashOutputs: 58d6a86eb99a911735d2f262a9fc13fcf0f8422d75e25ba04db120f65cf573d6
nLocktime: 00000000
sighash: 01000000


This will give me the MessageHash = 8560e61d0167f784d0cdaf9d45ba0e1be752e94d30a34339d976b01e50f0e366

But if i try to verify this MessageHash with the first Signature(473044022014cd600863ad3c9f6802383fe814a693a77144117cf7694f63b558b8c02d801c02201c3ad9901f659742668caf770f3d7f89a3633f9ccd2bfdd6a7c6f7529fe7b43101), which has R = 14cd600863ad3c9f6802383fe814a693a77144117cf7694f63b558b8c02d801c and S = 1c3ad9901f659742668caf770f3d7f89a3633f9ccd2bfdd6a7c6f7529fe7b431 against any of the 3 PubKeys in Witness 0 3, i always get the the Signature is not valid.

Can someone tell me where i got wrong ?

transactions: limitations in the custom script P2WSH

I did a stupid custom validation script in P2SH where after verification signature check if OP_3 equals OP_3. Now I want to move the same logic in P2WSH multisignatue 1-3.

it's my script

$ bitcoin-cli decodescript 512103dee28d1db5d8b92181ac5baa04c28c01d2b14d19a3c6adaf7bd3430d0c6c8146210343a6f95f841b48ba2b97822a546976aea951e5a1f1c0a10078fdbbded165dbe32103f2f0a25413bb97af3b2ef21694fab820146e2e1bed41b6528a9ce6dd218d9bd353AE755387 
    {
      "asm": "1 03dee28d1db5d8b92181ac5baa04c28c01d2b14d19a3c6adaf7bd3430d0c6c8146 0343a6f95f841b48ba2b97822a546976aea951e5a1f1c0a10078fdbbded165dbe3 03f2f0a25413bb97af3b2ef21694fab820146e2e1bed41b6528a9ce6dd218d9bd3 3 OP_CHECKMULTISIG OP_DROP 3 OP_EQUAL",
      "type": "nonstandard",
      "p2sh": "2N6SWbfkKVhPhYXx9idgDG5AVTPSAMNG5tY",
      "segwit": {
        "asm": "0 e976e1bb7c72f7f82132c706b3e8f2ee5673b9fa7172035aab9be62e8877d37c",
        "hex": "0020e976e1bb7c72f7f82132c706b3e8f2ee5673b9fa7172035aab9be62e8877d37c",
        "reqSigs": 1,
        "type": "witness_v0_scripthash",
        "addresses": [
          "bcrt1qa9mwrwmuwtmlsgfjcurt868jaet88w06w9eqxk4tn0nzazrh6d7qm9wxcj"
        ],
        "p2sh-segwit": "2NCLN7WkLL7dt56XyMVWH3QxDv2ytJGEw6d"
      }
    }

then create the transaction, sign it manually and add 3 in my Witness field, then I have

"5300"    

But I receive an error during the shipping transaction TX decode failed
The change 0x5300 with 0x010300 and works.

The question is, are there any limitations on the custom script in P2WSH? I did not find in BIP.
In P2SH I can add 0x53 in scriptSig and send the transaction without problems

bitcoin core: is the dust output limit the same for p2wpkh and p2wsh?

I just realized that there are, in fact, these two lines that take into account the size of CTxOut:

size_t nSize = GetSerializeSize(txout);
...
...
nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);

Based on this, a p2wsh output (43 bytes) would have a dust limit of:

= 43 + (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4)
= 110 bytes

then using the actual_relay_tx_fee dust of 3000 sat / kilobyte (or 3 sat / byte),

110 bytes * 3 sat / byte = 330 satoshis

Therefore, p2wsh outputs with less than 330 satoshis will be considered non-standard and will be rejected.

transactions – Manually sign native P2WSH with Openssl

I am studying the segwit part, and I want to sign P2WSH (native) manually (openssl).

I just read the BIP0143 and I see the new summary of the transaction.

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

I am using regtest and create a transaction from my P2WSH to P2WPKH where I move ~ 49.999991 bitcoins.

It's my UTXO

020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff03510101ffffffff0200f2052a010000002200204cad4226bdd3348214c78899b62c1b9c39b89770ae906157251579eca66188430000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000

My raw transaction details are:

02000000011bcf21f290fc42f902400f51ae4ccf2d08bbe23046489a58805de36395eeb9460000000000ffffffff017cee052a010000001600141231679927d0e4e91d4cf53aafe5338793a12e6700000000

And I create the new transaction summary like this:

TX_VERSION: 02000000
OUTPOINT: 1bcf21f290fc42f902400f51ae4ccf2d08bbe23046489a58805de36395eeb94600000000
HASH_PREV_OUT: 78486ab612702261a2a4a11fed91e08b7f6f04ecce2f1d9bce14291bb434e9d5
SEQUENCE: ffffffff
HASH_SEQUENCE: 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044
SCRIPTCODE: 00204cad4226bdd3348214c78899b62c1b9c39b89770ae906157251579eca6618843
AMOUNT: 7cee052a01000000
OUTPUT: 1600141231679927d0e4e91d4cf53aafe5338793a12e67
OUTPUT_HASH: 3ebf0a96b31050db258f1aeecc6e3754d10275e902e304977b152a778cec47bf
LOCKTIME_PART: 00000000
SIGHASH: 01000000

Where SCRIPT-CODE is my UTXO scriptpubkey hex (witness version-witness program)
Then I "merge" all the values ​​like this:

$ WITNESS_V0_DIGEST=$TX_VERSION$HASH_PREV_OUT$HASH_SEQUENCE$OUTPOINT$SCRIPTCODE$AMOUNT$SEQUENCE$OUTPUT_HASH$LOCKTIME_PART$SIGHASH
$ echo $WITNESS_V0_DIGEST
0200000078486ab612702261a2a4a11fed91e08b7f6f04ecce2f1d9bce14291bb434e9d53bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e706650441bcf21f290fc42f902400f51ae4ccf2d08bbe23046489a58805de36395eeb9460000000000204cad4226bdd3348214c78899b62c1b9c39b89770ae906157251579eca66188437cee052a01000000ffffffff3ebf0a96b31050db258f1aeecc6e3754d10275e902e304977b152a778cec47bf0000000001000000

So I can double SHA56 and sign it:

printf $WITNESS_V0_DIGEST | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b | xxd -r -p > WITNESS_V0_DIGEST.txt

SIGNATURE=`openssl pkeyutl -inkey private_key_1.pem -sign -in WITNESS_V0_DIGEST.txt -pkeyopt digest:sha256 | xxd -p -c 256`

SIGNATURE="${SIGNATURE}01"

Now I can create my transaction like so:

020000000001011bcf21f290fc42f902400f51ae4ccf2d08bbe23046489a58805de36395eeb9460000000000ffffffff017cee052a010000001600141231679927d0e4e91d4cf53aafe5338793a12e6703483045022100d44d8188f3d409d00a548e8fd28519d6b79d91b6e68d552f292d10e5e5cfb1340220449f0d26a9664167e5c2dda708067519a0dc9add614cbdd91c5e95bc8c646ecf012102ddefe0607cdc2cc7d19da88882fb4984105d166c52208c00f7ec6e232c4f2b341976a914feb8e763134e75edf22c1787ee3afb9687aa6a9f88AC00000000

It is the decoded version

{
  "txid": "b6953ac64ce5904263893f2a731bf8d06cf7e9ab6cc67f2078a771aceb6be067",
  "hash": "f705151ba17384c213d64ffe551b7a18f9d926227322a0de9d427dfed4a0c1bb",
  "version": 2,
  "size": 218,
  "vsize": 116,
  "weight": 464,
  "locktime": 0,
  "vin": (
    {
      "txid": "46b9ee9563e35d80589a484630e2bb082dcf4cae510f4002f942fc90f221cf1b",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": (
        "3045022100d44d8188f3d409d00a548e8fd28519d6b79d91b6e68d552f292d10e5e5cfb1340220449f0d26a9664167e5c2dda708067519a0dc9add614cbdd91c5e95bc8c646ecf01",
        "02ddefe0607cdc2cc7d19da88882fb4984105d166c52208c00f7ec6e232c4f2b34",
        "76a914feb8e763134e75edf22c1787ee3afb9687aa6a9f88ac"
      ),
      "sequence": 4294967295
    }
  ),
  "vout": (
    {
      "value": 49.99999100,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 1231679927d0e4e91d4cf53aafe5338793a12e67",
        "hex": "00141231679927d0e4e91d4cf53aafe5338793a12e67",
        "reqSigs": 1,
        "type": "witness_v0_keyhash",
        "addresses": (
          "bcrt1qzgck0xf86rjwj82v75a2lefns7f6ztn8lypwku"
        )
      }
    }
  )
}

But when I try to send it (sendrawtransaction), I get this error:

error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

address – P2WSH checksum failed

My goal is to replicate the same P2WSH from https://en.bitcoin.it/wiki/BIP_0173

tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

I am able to generate the "first" part before the checksum.
There is my binary

00000 00011 00001 10001 10001 01000 01111 00000 10100 11000 10100
01011 00110 10000 00001 00101 11101 00011 00100 10000 00011 00110
10101 10110 11010 00010 01101 10110 01001 10000 10101 10011 11000
11001 10101 00110 10010 01111 01000 01101 11000 11000 11000 11001
01001 01100 00001 00100 10000 00110 01001 10001

And its values ​​in base10

0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16,
3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8,
13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17

After that I use the Python function

python -c "import bech32; print bech32.bech32_create_checksum('tb', (0, 3, 1, 17, 17, 8, 15, 0, 20, 24, 20, 11, 6, 16, 1, 5, 29, 3, 4, 16, 3, 6, 21, 22, 26, 2, 13, 22, 9, 16, 21, 19, 24, 25, 21, 6, 18, 15, 8, 13, 24, 24, 24, 25, 9, 12, 1, 4, 16, 6, 9, 17) )"

And I get that result:

(3, 1, 3, 10, 2, 25)

After that I can map in charset ("qpzry9x8gf2tvdw0s3jn54khce6mua7l")

The end result is:
My address is:

tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3rpr2ze

the address of https://en.bitcoin.it/wiki/BIP_0173

tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

As you can see the problem is just the checksum, the first part tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3 is the same.

segregated token – Generate native P2WSH

I want to create native P2WSH like https://en.bitcoin.it/wiki/BIP_0173.
I already have a script to generate P2WPKH and it works, thanks to the Python part and rearranging the group byte jobs.

I read that witnessScript (scriptPubKey) is hashing of SHA256 without RIPEMD160.
Below a little of my code.

PB=0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798

#REDEEM SCRIPT  OP_CHECKSIG
SCRIPT=210279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798AC

#SCRIPT HASH
$ printf $SCRIPT | xxd -r -p | openssl sha256| sed 's/^.* //'
1863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

#SCRIPTPUBKEY
00201863143c14c5166804bd19203356da136c985678cd4d27a1b8c6329604903262

#Add Witness program,Convert in base2 the Public key and create groups of 5 bits
00000
00100
11110
01101
11110
01100
11001
11111
01111
10011
10111
00101
11011
10101
10001
01010
11010
00000
11000
10100
10101
11001
11010
00011
10000
10110
00001
11000
00010
10011
01111
11110
01101
10110
01011
01110
01110
00101
00011
01100
10101
10011
11100
10100
00001
01011
01100
01011
01111
10000
00101
11100
11000

#convert them in base10 and map on dictionary with python 
# use python to get checksum
... omit the code...

my result is:

tb1qy7d7vel0nh9m4326qc54e6rskpczn07dktww9rv4nu5ptvt0s9uc7wp7hd

but the result in BIP 0173 is

tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7

I even try to use scripthash to generate binary blocks, but with no luck.
Another question: can I create these addresses (P2WPKH and native P2SH) from bitcoin-cli?

Why is a 20-byte hash acceptable in p2wpkh but p2wsh needs 32 bytes?

Why is it acceptable to use a 20-byte hash to represent single sign token programs, while a 32-byte hash is used to pay for the token script hash?

Lightning Network – Help to sign a P2WSH Multisig

I am trying to build a transaction in regtest mode that spends from a P2WSH 2-of-2 multisig.

Here is the 5 btc financing transaction. It also contains a change output for 5 btc.

020000000001013314dcdc95c9aee89b7b0324ff2b472d73561d29cbd0cb58b37009b7193573700100000017160014a41c072b586d97105728775b124a88041e43afd2ffffffff020065cd1d00000000220020f9b7fbe4a3a7a621a19e03ef53d91a6391da83615826cbafa3062d3b39adfd380065cd1d00000000160014331039b508a3ad5633c045b24d94489adbaba0a00247304402204538711966348202e3d91352c7e5b2b0a4a7dab503946bc90ce912fd26f407ca02201e4334064a150227acc24095a6685505ef568c8e1e8a4e7053aa389c395ddf26012103993a782afaa894a4ea296210a5e72d46924898e9df91a74e32435c52b044fb3700000000

This is the transaction I am trying to spend from the security deposit:

0200000000010135fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f300000000000ffffffff010084d717000000001600141a6053fa355499bad556165474ca9661fd517c2b040047304402207be65e2f6d5fd8f7fdb421b65bdd53a1d0c9656e6fd7a8b9bef4954b08bc4250022066156cc85b84a783a7431cafa20f6e92272a2d28a484dd2becc259fea69b687501483045022100b608f0955ec89d0e3ff5e40ca36fb141425ddf0c8ab3880f45c44ca90155fd5702206606bbde73f5bea1fbb5da07fc17445ea5a1018efcad79fcda058180e203dd220147522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae00000000

bitcoin-cli gives me this error message when I try to transmit it:

error code: -26
error message:
non-mandatory-script-verify-flag (Signature must be zero for failed CHECK(MULTI)SIG operation) (code 64)

These are the private keys associated with the tx trust:

privkey1 = "CF933A6C602069F1CBC85990DF087714D7E86DF0D0E48398B7D8953E1F03534B"
privkey2 = "BF933A6C602069F1CBC85990DF087714D7E86DF0D0E48398B7D8953E1F03534B"

and here is the preimage of transaction summary bip_143 that becomes SHA256 double, which is then signed with private keys:

hashPrevOuts ec4982463833211511676584168e5c2749598a966f84594d529ca4627af6f541

hash sequence 3bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e70665044

txid point of view 35fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f30

point index
00000000

scriptCode
522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae

input_amount
0065cd1d00000000

sequence
ffffffff

hashOutputs
0c4a4515b0c862221d8376400bef5e085aba67281d774776f1bc083294180d6b

closing time
00000000

sighash
01000000

Preimage of complete digestion bip143 tx:
02000000ec4982463833211511676584168e5c2749598a966f84594d529ca4627af6f5413bb13029ce7b1f559ef5e747fcac439f1455a2ec7c5f09b72290795e7066504435fff0ef75190ac3ead75b46713fb63da6bf642b4e064856d5778a3e21615f3000000000522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae0065cd1d00000000ffffffff0c4a4515b0c862221d8376400bef5e085aba67281d774776f1bc083294180d6b0000000001000000

Any help with what might be happening or what to try would be greatly appreciated.

script: what is the scriptCode in a P2WSH transaction?

Let's say I'm spending a multisig of 2 of 2 with this script:
522103c2f21de0f430251d8e3987fbe89ff51f3d6f3a48b234b84b60ddb9f24d587cf52103e0948a03f50377290847d27c93d383b8ab7e2d0bc065e96e0e1136b315388b5452ae

OP_2 OP_2 OP_CHECKMULTISIG

What would go in the scriptCode according to BIP143? Is it just the script mentioned above? Here is the relevant part of BIP143.

For the P2WSH witness program,
– If the Script token does not contain any OP_CODESEPARATOR, the script code is the serialized token Script as scripts within CTxOut.
– If the Script token contains any OP_CODESEPARATOR, the scriptCode is the Script token but deletes everything until the last OP_CODESEPARATOR executed before the signature verification operation code is executed, serialized as scripts within CTxOut. (The exact semantics are demonstrated in the examples below)