P2P Network

Bitcoin is a gossip network of peers. There is no central server that “is Bitcoin.” Your node connects to other nodes, validates rules, and relays data.

Complete Step 1 // Required reading in the study plan above, then continue here. This opens Protocol Depth.

Step 2 — Core idea: discover, validate, gossip

Wallet backends, explorers, and Lightning nodes depend on healthy P2P connectivity. Sync problems, eclipse risks, and privacy leaks start at the network layer.

Analogy: Nodes as neighbors on radios. When someone announces a new transaction or block, others rebroadcast after validation. Compact tricks let them share “what’s new” without repeating everything they already have.

• Compact block relay (BIP-152) reconstructs new blocks using mempool txs already known
• Compact block filters (BIP-157/158) help light clients find relevant txs with better privacy than old bloom filters

Builder habits

• Run your own node for production backends when possible
• Monitor peer count and IBD/sync state
• Rate-limit and authenticate RPC — never expose it publicly

Done when: You can explain why compact blocks speed gossip without skipping validation.

Step 3 — Try it: inspect peers (lab)

bitcoin-cli -regtest getnetworkinfo
bitcoin-cli -regtest getpeerinfo

On a solo regtest node, peer count may be zero — that is fine. Note connection fields and sync/IBD-related status. On Polar or a mainnet/testnet node, compare peer diversity.

Common mistakes

• Exposing bitcoind RPC to the internet
• Assuming one explorer API equals full network view
• Ignoring that different peers may temporarily see different mempools

Done when: Lab evidence (network/peer excerpt + observation + source link) is complete.

Next lesson

P2P Adversarial Thinking — eclipse, partitions, and hardening habits for operators.