Network Propagation and Peer Discovery

A new node has no central Bitcoin server to contact. It can begin with remembered peer addresses, DNS seeds supplied by the software, manually configured peers or other discovery methods.

DNS seeds return possible peer addresses; they do not provide trusted blockchain data. Every connected peer remains an untrusted source whose messages must be validated.

After opening a connection, peers complete a version handshake and advertise supported services. Nodes can also share addresses so their peers learn about other reachable nodes.

Connections are selected and managed to reduce dependence on one network region or address source. A large displayed peer count alone does not prove a node has a diverse view.

Peers commonly announce data by identifier before the receiver requests what it lacks. Transactions may be announced with inventory messages, while compact block relay can reconstruct a block from transactions already known to the receiving node.

This request-and-response pattern reduces duplicate traffic, but propagation is not instantaneous or identical. Different nodes have different connections, policies and mempools.

A received transaction is checked before it enters the local mempool and is relayed under the node's policy. A received block must satisfy proof of work and every relevant consensus rule before it joins the active chain.

Relaying an item does not make it valid by popularity. A thousand peers cannot make a correctly operating full node accept a block that breaks its consensus rules.

Observers controlling or monitoring many connections may infer where a transaction originated, while an eclipse attacker tries to isolate a node's network view. Diverse peer selection and protected network access help reduce these risks.

Tor can hide a node's public IP from peers in some configurations, but it changes network assumptions and does not provide complete anonymity. Privacy claims should remain bounded and testable.