<p>Note that witnesses are not scripts. They do not contain opcodes. They are stack elements. Witnesses do not have explicit opcodes (witnessScripts are scripts but are single witness stack elements so their opcodes don't count).</p>

<p>The count is used as it clearly delineates between the end of the stack items for an input and the beginning of the stack items for the next input. The use of a count follows the standard serialization methodology used elsewhere in Bitcoin for serializing arrays of items. In this case, the witness data for an input is an array of arrays of bytes (in code, that's <code>std::vector&lt;std::vector&lt;unsigned char&gt;&gt;</code>). </p>

<p>So, following the standard serialization method of <code>std::vector</code>s, at the top level we get the number of items in the next level down (i.e. the number of <code>std::vector&lt;unsigned char&gt;</code> elements) which happens to be the number of stack items. Then the next level of serialization we get another length for the number of items in the level below (i.e. the number of <code>unsigned char</code> in each vector). So now we have the length of each stack item. Then comes the stack item itself.</p>

<p>The reason this method was used for segwit is likely because stacks in Bitcoin Core are implemented as <code>std::vector&lt;std::vector&lt;unsigned char&gt;&gt;</code>. Furthermore the serialization of vectors in this manner is used everywhere in Bitcoin so the serialization code for this basically already existed in every existing wallet software.</p>

CC BY-SA 4.0
2019-03-29T17:49:49.713Z
2019-03-29T17:49:49.713Z
Ava Chow
<p>In legacy transaction (without SegWit) the scriptSig is easily parsed by knowing the length of it (a <code>CompactInt</code> value) and without needing to read the script in place.<br>
However in SegWit transaction the scriptSig that is moved to witness position is now identified by a "count" of the items inside of the script and that means script needs to be read (interpreted) in place.<br>
Was size (saving 2 bytes in multi-sig scripts) the only reason for this difference?<br>
Also is there any restrictions on OP codes that could be used in scripts inside witnesses because of this difference?</p>

<segregated-witness><raw-transaction>
Why does witness use count instead of length?
Coding Enthusiast
# Why does witness use count instead of length?

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

In legacy transaction (without SegWit) the scriptSig is easily parsed by knowing the length of it (a `CompactInt` value) and without needing to read the script in place.  
However in SegWit transaction the scriptSig that is moved to witness position is now identified by a "count" of the items inside of the script and that means script needs to be read (interpreted) in place.  
Was size (saving 2 bytes in multi-sig scripts) the only reason for this difference?  
Also is there any restrictions on OP codes that could be used in scripts inside witnesses because of this difference?

**Tags:** segregated-witness, raw-transaction


---

## 1 answers

### Answer by username_1 on 2019-03-29. Score: 3 | Accepted answer

Note that witnesses are not scripts. They do not contain opcodes. They are stack elements. Witnesses do not have explicit opcodes (witnessScripts are scripts but are single witness stack elements so their opcodes don't count).

The count is used as it clearly delineates between the end of the stack items for an input and the beginning of the stack items for the next input. The use of a count follows the standard serialization methodology used elsewhere in Bitcoin for serializing arrays of items. In this case, the witness data for an input is an array of arrays of bytes (in code, that's `std::vector<std::vector<unsigned char>>`).

So, following the standard serialization method of `std::vector`s, at the top level we get the number of items in the next level down (i.e. the number of `std::vector<unsigned char>` elements) which happens to be the number of stack items. Then the next level of serialization we get another length for the number of items in the level below (i.e. the number of `unsigned char` in each vector). So now we have the length of each stack item. Then comes the stack item itself.

The reason this method was used for segwit is likely because stacks in Bitcoin Core are implemented as `std::vector<std::vector<unsigned char>>`. Furthermore the serialization of vectors in this manner is used everywhere in Bitcoin so the serialization code for this basically already existed in every existing wallet software.


---

