Bitcoin’s P2P network is not just plumbing. Peer selection, relay, and topology affect censorship resistance, privacy, and whether your node sees the same chain tip as the honest majority.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: eclipse, partitions, compact relay
Wallets and services that trust a small set of peers inherit those peers’ view of the mempool and chain. Protocol builders who ignore gossip security ship fragile products.
An eclipse attack aims to surround a victim with attacker-controlled peers so the victim’s view of the network is filtered. Related risks include BGP-level routing interference and intentional network partitions.
BIP-152 compact blocks reduce bandwidth when relaying new blocks by sending short transaction IDs peers likely already have. This improves propagation — it is not a substitute for validating consensus rules.
Loading diagram…
Operator habits
- Prefer diversity (ASNs, networks, onion where appropriate)
- Monitor peer churn and unexpected tip disagreements
- Separate listening services from keys when possible
Done when: You can name one eclipse symptom and one thing BIP-152 does not fix.
Step 3 — Threat note for your setup (lab)
Document your node’s peer settings (maxconnections, addnode/connect, onion vs clearnet). Write a short threat note covering eclipse and DoS for that setup, plus one concrete hardening change you would make.
bitcoin-cli -regtest getnetworkinfo
# Also note bitcoin.conf / Polar peer settings you actually useCommon mistakes
- Running a “full node” with one trusted outbound peer forever
- Assuming private RPC + public P2P needs no hardening
- Confusing relay policy DoS mitigations with consensus safety
Done when: Lab evidence (config export + threat note + one hardening change) is complete.
Next lesson
Security Models & Light Clients — full validation vs SPV, filters, and AssumeUTXO tradeoffs.