P2P Message Header: Serialization of the 24-Byte Wire Protocol

Every message transmitted over the Bitcoin peer-to-peer network is prepended with a standard, rigid 24-byte header. This header acts as the structural envelope, informing the receiving node of the payload's network origin, the operational command type, the payload length, and a payload checksum.

This guide details the byte-level serialization offsets and cryptographic validation rules of this wire-protocol header.

---

🗺️ 1. The 24-Byte Header Structure

The message header is structured exactly as a 24-byte contiguous array of memory. It consists of four fields:

                      THE 24-BYTE WIRE PROTOCOL HEADER

  Bytes: 0-3                4-15                     16-19          20-23
 ┌─────────────────────────┬────────────────────────┬──────────────┬──────────────┐
 │ Magic Bytes             │ Command Name (ASCII)   │ Payload Size │ Checksum     │
 │ 4 Bytes (uint32)        │ 12 Bytes (char[12])    │ 4 Bytes      │ 4 Bytes      │
 └─────────────────────────┴────────────────────────┴──────────────┴──────────────┘

Detailed Structural Byte Offsets

Offset (Bytes)	Field Name	Data Type	Endianness	Description
0 - 3	Magic Bytes	uint32_t	Little Endian	Identifies the target network (e.g., 0xF9BEB4D9 for Mainnet).
4 - 15	Command	char[12]	Raw (ASCII)	The name of the message (e.g., version), left-aligned and null-padded.
16 - 19	Payload Size	uint32_t	Little Endian	The size in bytes of the following serialized message payload.
20 - 23	Checksum	uint8_t[4]	Raw	The first 4 bytes of the double-SHA256 hash of the payload.

---

🔡 2. Command String Padding (char[12])

The Command field is always exactly 12 bytes long. Because message commands are represented in ASCII and are typically shorter than 12 characters (e.g., ping, pong, version), they must be padded to fill the allocation.

• Left Alignment: The command starts at byte index 4.
• Null Padding: Remaining trailing bytes must be filled with null bytes (\x00).

Hex Serialization Example:

For the command version: * ASCII representation: v, e, r, s, i, o, n * Hex representation: 76 65 72 73 69 6f 6e * Serialized 12-byte Command field: $$\texttt{76 65 72 73 69 6f 6e 00 00 00 00 00}$$

---

🔒 3. The Cryptographic Checksum Verification

To protect nodes from processing corrupt, incomplete, or malicious payloads, every header carries a 4-byte checksum.

Mathematical Formulation

The checksum represents the first 4 bytes of the double-SHA256 hash of the serialized payload array:

$$\text{Checksum} = \text{first 4 bytes of } \text{SHA256}\Big(\text{SHA256}\big(\text{Payload}\big)\Big)$$

Verification Pipeline

When a node parses an incoming wire message: 1. It reads the Payload Size (let's say $S$). 2. It reads exactly $S$ bytes from the socket to capture the complete payload. 3. It hashes the payload: $H = \text{SHA256}(\text{SHA256}(\text{Payload}))$. 4. It extracts the first 4 bytes of $H$ and compares them to the 4-byte Checksum field in the header. 5. If they do not match, the node throws a validation exception and drops the peer connection instantly.