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.
Loading diagram…
- 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 getpeerinfoOn 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
bitcoindRPC 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.