Bitcoin’s peer-to-peer network operates as a decentralized gossip system where nodes relay transactions and blocks without trusting one another. New nodes bootstrap by contacting hardcoded DNS seeds maintained by core developers. These DNS seeds return IPs of active peers, enabling nodes to discover the network and then request additional peers via getaddr. Networking is intentionally not consensus‑critical, so implementations may differ as long as consensus rules remain unchanged.

All Bitcoin P2P messages use a fixed envelope: a 4‑byte magic value (F9BEB4D9 for mainnet), a 12‑byte ASCII command, a 4‑byte little‑endian payload length, a 4‑byte checksum (first 4 bytes of hash256), and the payload. Common commands include version, verack, inv, getdata, tx, block, getheaders, headers, ping, and pong.

The handshake begins when a connecting node sends a version message. The receiver replies with verack and its own version. Once both sides exchange these two messages, the connection is active and nodes may begin relaying inventories and data.

Bitcoin stores a single 32‑byte Merkle root in each block header as a commitment to all transactions in the block. Transactions are hashed (hash256), paired, concatenated, and hashed repeatedly until one hash remains. When a level has an odd count, the last hash is duplicated. Internally, hashes are big‑endian, while serialized block data uses little‑endian, requiring reversals before and after tree construction.

Merkle proofs allow verifying that a transaction is included in a block without downloading the entire block. The proof consists of sibling hashes along the path to the root. Lightweight SPV clients store only block headers and request these proofs from full nodes. Because a Merkle tree grows logarithmically, proving inclusion in a block with thousands of transactions requires only a few hundred bytes.

Taproot extends this concept by committing spending conditions to a Merklized script tree (MAST), revealing only the executed branch along with a Merkle proof. This improves both efficiency and privacy.

Nodes use getdata to request transactions or blocks, specifying a type ID (1=tx, 2=block, 3=filtered block, 4=compact block) plus a 32‑byte identifier. For chain sync, nodes send getheaders with a starting block hash, receiving up to 2000 headers in response. Each returned header is 80 bytes followed by a dummy transaction count of zero.

Full verification of received blocks requires two checks:

Only if both conditions succeed does a node accept the block, reflecting Bitcoin’s “don’t trust, verify” principle.