Byte Serialization in Raw Transactions

A "Raw Transaction" is just a long string of hexadecimal characters. To a node, this string isn't just text; it's a sequence of tightly packed bytes that follow a strict schedule.

1. Fixed-Width Fields

Many fields in a Bitcoin transaction have a fixed size.

• Version: 4 bytes (8 hex characters).

• TXID Reference: 32 bytes (64 hex characters).

• Amount: 8 bytes (16 hex characters). Because the size is fixed, the node knows exactly where one field ends and the next begins.

2. Variable-Width Fields (VarInt)

What about fields that change size, like a message or a list of inputs?

• Bitcoin uses VarInt (Variable Length Integer).

• If a script is 20 bytes long, the VarInt prefix is 14 (hex for 20).

• If a script is 1,000 bytes long, the VarInt prefix is FD E8 03 (a special marker FD followed by the length in 2 bytes).

3. String Serialization

When Bitcoin stores a string (like a message or an address HRP), it doesn't use "Null Terminators" like the C programming language.

• It uses Length-Prefixed strings.

• [Length Byte] + [The Data]

• This makes parsing significantly more secure, as the computer knows exactly how much memory to allocate before reading the data.

4. Padding

In certain cryptographic structures (like DER Signatures), padding is used to ensure that the data fits specific mathematical requirements.

• If a number is exactly 32 bytes but its first bit is 1, a leading 00 byte is added to prevent it from being interpreted as a negative number.

5. Hex to Byte Converters

When you copy a hex string into a tool, the tool performs a "Decode":

1. Verify the length is even (2 hex chars per byte).

2. Map each pair to a decimal value (0–255).

3. Write that byte to a buffer.

Field	Size	Type
nVersion	4 Bytes	Fixed (LE)
Vin Count	1-9 Bytes	VarInt
Output Value	8 Bytes	Fixed (LE)

In the final section, we will build a Python Hex Auditor.