Glossary / Nodes & software
Message header
- Definition
- Bitcoin's message header is a fixed 24 bytes of envelope wrapped around every peer-to-peer message: a network start string, a command name, a payload length, and a checksum.
Nothing in the peer protocol describes itself, so the envelope has to do that job. Its four fields never change size or order, letting a node read exactly 24 bytes, learn how much more is coming, and hang up on anything claiming more than the 4,000,000 bytes Bitcoin Core will accept. You will never see one, but a malformed header is why a peer connection sometimes disappears without explanation.
How it works
The header's four fields are read in a fixed order, and each one gates what happens next.
Bytes 0 through 3 hold the start string identifying the network. Bytes 4 through 15 hold the command: a lowercase ASCII name padded with null bytes out to twelve characters, which is why every message type in bitcoin has a terse name and why cmpctblock, at ten characters, sits close to the ceiling. Bytes 16 through 19 hold the payload length as a little-endian unsigned integer. Bytes 20 through 23 hold a checksum, the first four bytes of a double SHA-256 taken over the payload.
Putting the length before the payload is the design's real safety feature. A node that has consumed 24 bytes already knows whether the sender is claiming something absurd, and Bitcoin Core refuses anything above 4,000,000 bytes and disconnects, without allocating a buffer or waiting on data that may never come. Put the length after the body and you are trusting the sender to stop.
The checksum deserves less respect than it usually gets. Four bytes of hash catch a flipped bit on a bad link, and they accomplish nothing against a peer that is lying, since a hostile sender simply computes the checksum over whatever it has chosen to send. Integrity in bitcoin comes from validating contents against consensus rules, never from this field.
The whole structure is optional in newer software. BIP324's version 2 transport encrypts the connection and replaces the plaintext envelope with obfuscated length framing plus a one-byte short identifier for the commonest message types, so a passive observer can no longer read command names off the wire. Bitcoin Core shipped it as an opt-in setting in version 26.0 and turned it on by default in a later release.
Where you see it
Message headers appear in packet captures and in a node's own diagnostics.
Run Bitcoin Core with -debug=net and the log records message types and sizes for every peer, which is the practical way to watch what a connection is actually doing. Entries reading PROCESSMESSAGE: INVALID MESSAGESTART mean a peer sent bytes that did not begin with this network's start string, which is nearly always something misconfigured on the other end rather than an attack. Wireshark's bitcoin dissector parses the same 24 bytes to label each frame.
Message header vs block header
A message header is transport packaging; a block header is consensus data, and they share nothing but the word. The message header is 24 bytes, exists only for the duration of one delivery, and is thrown away as soon as the payload has been read. The block header is 80 bytes, holds the version, the previous block's hash, the merkle root, the timestamp, the difficulty target and the nonce, and gets hashed to produce the proof of work that names that block permanently. One is the address label on a parcel; the other is what is inside it.