I'm looking at some raw txs (P2SH in that case) for learning, and I have one question about a particular tx: tx hash 0aeae24fa55544da49ba06ec338c9beee592ab4bea71eb8085908f377dd46084, i use this tool for analysis: https://hashxp.org/0aeae24fa55544da49ba06ec338c9beee592ab4bea71eb8085908f377dd46084

I don't understand its script length (fd fe 00). The value is analysed as 254 by the tool. So, why is the script length stored as 3 bytes, but only uses the value of the second byte?

Does anyone know a paper about how to build a standard P2SH tx?

1 Answer 1


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.

  • @cc1cc1: If RedGrittyBrick answered your question fully, you can accept his answer as the most helpful by clicking the checkmark.
    – Murch
    Commented Sep 27, 2022 at 13:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.