<p>There is no restriction due to segwit, but witnesses are serialized differently than scriptSigs.</p>

<p>A scriptSig is a script on itself, which gets executed, and its resulting stack is then fed to the scriptPubKey (or redeemScript in case of P2SH). This is not the case for the witness: it is an encoding of the stack directly, without script involved.</p>

<p>That means that scriptSig can use opcodes like OP_3 (which pushes the byte array 0x03 onto the stack). In the witness, you'd need to serialize that byte array directly as 0x0103. The 0x01 there is <em>not</em> an opcode; it is just the length of the stack element.</p>

CC BY-SA 4.0
2020-04-28T17:32:16.340Z
thanks! I presume that for the same reason witness field doesn't have length in transaction data, but just the #stack item to push in.
monkeyUser
CC BY-SA 4.0
2020-04-28T17:34:00.850Z
Correct. Scripts are serialized as a byte array (so they're prefixed with their total length), and then executed by interpreting opcodes. Witnesses are serialized as an array of byte arrays (so prefixed overall with the number of stack elements, and then each stack element is prefixed with its length).
Pieter Wuille
CC BY-SA 4.0
2020-04-28T17:18:15.360Z
2020-04-28T17:18:15.360Z
Pieter Wuille
<p>I did a stupid custom validation script in P2SH where after check signature, check if OP_3 is equal of OP_3. Now I want to move the same logic in P2WSH multisignatue 1-3.</p>

<p>it's my script</p>

<pre><code>$ 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"
      }
    }
</code></pre>

<p>then create the transaction, manually sign it and add 3 in my Witness field, Then I have</p>

<pre><code>"5300"&lt;signatures&gt;&lt;witness script&gt;    
</code></pre>

<p>But I get an error during send transaction <code>TX decode failed</code>
The I change <code>0x5300</code> with <code>0x010300</code> and it works.</p>

<p>The Question is, are there some limitation on custom script in P2WSH? I didn't find in BIP.
In P2SH I able to add <code>0x53</code> in scriptSig and send transaction without problems</p>

CC BY-SA 4.0
2020-04-28T17:03:01.440Z
Perhaps unrelated to your question, but how do you expect a script like this to work? The OP_FROMALTSTACK operation will fail the script immediately, because the alt stack is empty at that point.
Pieter Wuille
CC BY-SA 4.0
2020-04-28T17:07:26.643Z
@PieterWuille my mistake, I pasted even the length. Updated :)
monkeyUser
<transactions><segregated-witness>
Limitations in P2WSH custom script
monkeyUser
# Limitations in P2WSH custom script

(Asked by: username_0 on 2020-04-28)

I did a stupid custom validation script in P2SH where after check signature, check if OP\_3 is equal of 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, manually sign it and add 3 in my Witness field, Then I have

```
"5300"<signatures><witness script>    

```

But I get an error during send transaction `TX decode failed`
The I change `0x5300` with `0x010300` and it works.

The Question is, are there some limitation on custom script in P2WSH? I didn't find in BIP.
In P2SH I able to add `0x53` in scriptSig and send transaction without problems

**Tags:** transactions, segregated-witness

> **Comments:**
> **username_1**: Perhaps unrelated to your question, but how do you expect a script like this to work? The OP_FROMALTSTACK operation will fail the script immediately, because the alt stack is empty at that point.  
> **username_0**: @username_1 my mistake, I pasted even the length. Updated :)  

---

## 1 answers

### Answer by username_1 on 2020-04-28. Score: 4 | Accepted answer

There is no restriction due to segwit, but witnesses are serialized differently than scriptSigs.

A scriptSig is a script on itself, which gets executed, and its resulting stack is then fed to the scriptPubKey (or redeemScript in case of P2SH). This is not the case for the witness: it is an encoding of the stack directly, without script involved.

That means that scriptSig can use opcodes like OP\_3 (which pushes the byte array 0x03 onto the stack). In the witness, you'd need to serialize that byte array directly as 0x0103. The 0x01 there is *not* an opcode; it is just the length of the stack element.

> **Comments:**
> **username_0**: thanks! I presume that for the same reason witness field doesn't have length in transaction data, but just the #stack item to push in.  
> **username_1**: Correct. Scripts are serialized as a byte array (so they're prefixed with their total length), and then executed by interpreting opcodes. Witnesses are serialized as an array of byte arrays (so prefixed overall with the number of stack elements, and then each stack element is prefixed with its length).  

---

