8 Peer to peer network

This chapter replaces the last central bottleneck—the shared folder—with a decentralized peer-to-peer network. In this gossip-style network, full nodes (including miners) connect to several peers and relay information directly, making block and transaction propagation fast and resilient. Because no single administrator decides what gets through, censorship becomes far harder: even if one node withholds data, others forward it. Wallets also benefit by broadcasting transactions to the entire network without knowing who the miners are, removing the need for miner address lists and improving discoverability and speed.

The chapter traces how data moves across the network and how peers communicate. Nodes connect over TCP (commonly to port 8333), perform a version/verack handshake, and then speak a shared protocol: new transactions are announced with inv, fetched with getdata, and sent with tx; new blocks are announced and fetched using headers, getdata, and block (per modern propagation like BIP130). Lightweight wallets use bloom filters to request only relevant data and receive compact merkleblock proofs to verify inclusion without downloading full blocks. This lets recipients learn about pending payments quickly (0-conf) and later confirm them as blocks arrive and accumulate work.

The second half explains how a new node boots up and joins the network. After installing software (e.g., Bitcoin Core) and verifying release signatures, a node discovers peers via manual entries, DNS seeds, or hard-coded seeds, then expands its view with getaddr/addr while maintaining multiple connections for robustness. It synchronizes by downloading headers first (getheaders/headers) to find the best chain, then pulls blocks in parallel (getdata/block), verifies proof of work and transactions, and builds the UTXO set—optionally skipping signature checks on very old blocks to accelerate initial download. Once caught up, the node enters normal operation, validating, relaying, and participating fully on the network; at this point the cookie-token scaffolding is discarded because the model now matches Bitcoin exactly.

   Bitcoin’s peer to peer network

  The shared folder is a central point of authority

  In a peer to peer network, blocks are being passed on from one node to another. Much like how gossip spreads among people.

  Transactions travel the peer to peer network just like blocks do. Wallets don’t need to know the miners anymore.

  Tom’s computer program sets up a TCP connection to Lisa’s computer program. After this they can send and receive data between each other.

  Lisa must be able to understand what Tom writes on the channel.

  Lightweight wallets communicate with nodes using the Bitcoin network protocol.

  Tom’s node is informed about John’s transaction so that Tom can fetch it.

  Tom forwards the transaction to his friends.

  Tom’s node sends the transaction to Qi’s node by using the familiar three-step process

  Lisa’s node sends an inv to Qi’s node, but Qi’s node already has the transaction

  The cafe’s lightweight wallet has a TCP connection to their own full node

  The cafe’s wallet gets John’s transaction from their trusted node after being checked against the bloom filter.

  Rashid’s block containing John’s transaction

  Rashid’s node sends Rashid’s block to Qi’s node

  All but Lisa has the block. Tom, Cafe and Qi send headers messages.

  Tom sends a merkleblock containing a merkle proof that John’s transaction is in the block.

  The merkleblock contains a block header and a partial merkle tree.

  The cafe requests a merkleblock from their trusted full node

  As more blocks arrive, John’s transaction becomes safer and safer

  The cookie token system evolution.

26   The Bitcoin network distributes blocks (and transactions) to all participants.

  Running a full node involves, downloading and running the software, connect to other nodes, download old blocks and enter normal operation

  The Bitcoin Core team signs the released program with their private key

  Selma verifies the Bitcoin Core signature and that the hash in the signature file matches the hash of the actual program.

  Selma’s full node has three different types of sources to find initial peers

  Selma requests more peer addresses from Rashid’s node. He responds with a bunch.

  Selma downloads block headers from Tom by repeatedly sending a getheaders message with her latest block id.

  Selma downloads blocks from Tom by repeatedly sending a getblocks message with her latest block id.

  Selma is finally an active part of the Bitcoin peer to peer network

  The Bitcoin Core team signs the released program with their private key

  Johns transaction propagates to all participants

  Rashid’s block containing John’s transaction propagates to all participants

  Selma goes through four steps to join the network

• The peer to peer network makes blocks censorship resistant
• A node connects to multiple peers to reduce their vulnerability for information hiding.
• The Bitcoin network protocol is the "language" nodes speak to communicate.
• Transactions are broadcast on the Bitcoin peer to peer network to reach both miners and the recipient of the money early.
• New nodes synchronize with the Bitcoin network to get up to date with the other nodes. Takes hours or days.
• Nodes do not need to stay on-line 24/7. They can drop out and come back and sync up the latest stuff.
• Signature verification can be skipped for older blocks to speed up initial synchronization. This is useful if you know that a specific block is valid.

FAQ