If we look at the network format of the input section of a transaction message we see
| Field |
Description |
Size |
| Previous Transaction hash |
doubled SHA256-hashed of a (previous) to-be-used > transaction |
32 bytes |
| Previous Txout-index |
non negative integer indexing an output of the to-> be-used transaction |
4 bytes |
| Txin-script length |
non negative integer VI = VarInt |
1 - 9 bytes |
| Txin-script / scriptSig |
Script |
<in-script length>-many bytes |
| sequence_no |
normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0 |
4 bytes |
So the Txin-script length is of type Varint.
Variable length integer
Integer can be encoded depending on the represented value to save space. Variable length integers always precede an array/vector of a type of data that may vary in length. Longer numbers are encoded in little endian.
| Value |
Storage length |
Format |
| < 0xFD |
1 |
uint8_t |
| <= 0xFFFF |
3 |
0xFD followed by the length as uint16_t |
| <= 0xFFFF FFFF |
5 |
0xFE followed by the length as uint32_t |
| - |
9 |
0xFF followed by the length as uint64_t |
(my emphasis)
So for script-lengths longer than 0xfc and less than 0xffff the script-length is represented as a Varint with three bytes, the first byte of which must be 0xfd so that the format can be unambiguously differentiated from other lengths of Varint.
If the first byte we read is lower than 253 (0xFD) we know the Varint is one byte long and the value we just read is the length of the script.
If the first byte we read is 253 (0xFD) we know the Varint is three bytes long and we need to discard this byte and read the next two bytes as the length of the script.
Ditto 254 (0xFE), five bytes, next four.
Ditto 255 (0xFF), nine bytes, next eight.
So we can't represent a script length of 254 in a one-byte Varint because 254 (0xFE) is a special marker byte-value for a five-byte Varint. Instead of using a one-byte Varint, we have to go to the next size up of Varint - a three-byte Varint, and use it's special marker byte value to prefix a two-byte (Uint16_t) length value.
The endianness of the Uint16_t is why the first byte of the last two is the lowest part of the Uint16_t value. 254 is 0x00FE but in little-endian byte-order that is 0xFE00.
What this teaches us is that the developers of this network protocol prioritised compactness of message size over clarity and simplicity.
Given the prevalence of other protocols that take the opposite approach to message size (consider SMTP with XML payloads like DOCX etc or HTTP with HTML payloads) it must be debateable whether this was a necessary or good choice. Maybe a simpler, less confusing choice could have been used, optionally wrapped in a compression envelope. But the choice was made and I guess it is one that Bitcoin developers must live with.
