Peer-to-Peer Overlay Network
Bitcoin's Peer-to-Peer (P2P) overlay network enables peer discovery and provides broadcast information propagation. The network is sparsely connected by default. A fraction of the Bitcoin peers (e.g., full nodes) provide incoming TCP connections on port 8333 (typically full Bitcoin nodes) to which other peers can connect. SPV clients in particular do not provide direct services to the P2P overlay network and only receive information relevant to their addresses.
Upon initialization, a Bitcoin node is typically not aware of other full nodes' IP addresses. The client therefore queries DNS servers (called DNS seeds) which provide, for bootstrap purposes, a list of IP addresses of full Bitcoin peers. The DNS seeds are maintained by Bitcoin community members: some provide dynamic DNS seed servers that automatically acquire IP addresses of active nodes by scanning the network; others provide static seeds that are updated manually.
Once a peer has received a list of full Bitcoin node IP addresses, the peer performs up to eight outgoing connection attempts; the eight nodes that the peer attempts connection with are referred to as entry nodes. In order to diversify the number of peers that a node is aware of, a node can request from its neighbors the IP addresses of other peers that they are aware of using the addr P2P network message. Note that a peer replaces dynamically any dropped or failed entry connections. There is otherwise no default connection renewal foreseen by the peers until the node resets. A Bitcoin node can connect to a default number of 125 TCP connections. Note that nodes can change this default number in their clients (and recompile the code) in order to establish more than 125 concurrent TCP connections.
Though the Bitcoin daemon does not explicitly distinguish between clients and servers, Bitcoin peers can be grouped into those which can accept incoming connections (servers) and those which cannot (clients), such as peers behind NAT or firewall.
The Bitcoin protocol implements an IP address propagation mechanism to help peers discover other peers in the P2P network. Each Bitcoin peer maintains a list of IP addresses of other peers in the network and each address is given a time stamp that determines its freshness. Peers can request IP addresses from this list from each other (through getaddr messages) and/or advertise to the network IPs known to it (through addr messages). Upon receiving an addr message from the network, a peer checks if it is well formed (i.e., contains less than 11 IPs), and parses the IPs listed within to decide whether to forward it to its neighbors. More specifically, the peers check if each of the addresses advertised are fresh (using the time stamp field), and if so, they forward it to two neighbors of their choice. Note that by limiting the number of neighbors to which an address is forwarded, the overall messages exchanged among peers in the Bitcoin P2P network is inherently reduced.
Assuming a reachable address, Bitcoin peers choose a subset of their neighbors (also known as responsible nodes) that will receive the address advertisement. This selection is performed by computing the hash of the forwarding address concatenated with a secret salt, current date, and the memory address of the data structure describing the neighbor. Only two neighbors (the first two) are selected in this process.
Once the neighbors are selected, the transmission of the scheduled messages (i.e., the address in this case) is performed in rounds lapsing 100 milliseconds each. In each round, the corresponding addr messages are pushed to the randomly selected neighbors. This process of pushing addr messages is also known as trickling, and the chosen node as trickle node.
When a peer receives a getaddr message, it sends back a bounded number of addresses that it is storing. The number of addresses sent is set to around 23% of the total number of stored addresses without exceeding the threshold of 2500 addresses. To avoid flooding the network with unnecessary messages, Bitcoin peers maintain a history of the addresses that have been announced for each neighbor. Thus, a peer would only advertise once the same address over a connection. Note that this history is per connection (and not per IP), and is cleared every 24 hours. In addition, there is an upper bound of the total number of addresses that a peer can locally store (currently around 20K); old addresses are replaced by newly received ones whenever this limit is reached.
For each received address, the peer assigns a score as follows: the local interfaces initially are assigned with low scores (i.e., 1), while external IP addresses receive high scores (i.e., 4).