title: The Bitcoin Network theme: sjaakvandenberg/cleaver-light
The Bitcoin Network
Decentralized P2P Consensus Network
- Decentralization of control is a core design principle that can only be achieved and maintained by a flat, decentralized P2P consensus network.
- Blockchains are politically decentralized (no one controls them) and architecturally decentralized (no infrastructural central point of failure) but they are logically centralized (there is one commonly agreed state and the system behaves like a single computer)
Peer-to-Peer Network Architecture?
- Bitcoin is structured as a peer-to-peer network architecture on top of the internet.
- The term “bitcoin network” refers to the collection of nodes running the bitcoin P2P protocol
Node Types and Roles
- A bitcoin node is a collection of functions: routing, the blockchain database, mining, and wallet services.
- All nodes include the routing function to participate in the network and might include other functionality.
- All nodes validate and propagate transactions and blocks, and discover and maintain connections to peers.
Full Nodes
- Full blockchain nodes maintain a complete and up-to-date copy of the bitcoin blockchain with all the transactions, which they independently build and verify
- Starting with the very first block (genesis block) and building up to the latest known block in the network.
- In the past two years, however, new forms of bitcoin clients have been introduced that do not maintain a full blockchain but run as lightweight clients.?
Mining Nodes?
- Mining nodes compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm.
- Some mining nodes are also full nodes, maintaining a full copy of the blockchain, while others are lightweight nodes participating in pool mining and depending on a pool server to maintain a full node.
Simplified Payment Verification (SPV) Nodes?
- Some nodes maintain only a subset of the blockchain and verify transactions using a method called simplified payment verification, or SPV. These nodes are known as SPV nodes or lightweight nodes.
- User wallets might be part of a full node, as is usually the case with desktop bitcoin clients. Increasingly, many user wallets, especially those running on smartphones, are SPV nodes.
Edge Routers
- Various large companies interface with the bitcoin network by running full-node clients based on the Bitcoin Core client, with full copies of the blockchain and a network node, but without mining or wallet functions.
- These nodes act as network edge routers, allowing various other services (exchanges, wallets, block explorers, merchant payment processing) to be built on top.
The Extended Bitcoin Network
- Attached to the main bitcoin P2P network are a number of pool servers and protocol gateways that connect nodes running other protocols.
- These other protocol nodes are mostly pool mining nodes and lightweight wallet clients, which do not carry a full copy of the blockchain. For example, Stratum servers connect Stratum mining nodes via the Stratum protocol to the main bitcoin network and bridge the Stratum protocol to the bitcoin P2P protocol.
Bitcoin Relay Network
- A Bitcoin Relay Network is a network that attempts to minimize the latency in the transmission of blocks between miners.
- FIBRE is a UDP-based relay network that relays blocks within a network of nodes. FIBRE implements compact block optimization to further reduce the amount of data transmitted and the network latency.
- Falcon uses "cut-through-routing" instead of "store-and-forward" to reduce latency by propagating parts of blocks as they are received rather than waiting until a complete block is received.
Network Discovery
- a new node must discover at least one existing node on the network and connect to it. To connect to a known peer, nodes establish a TCP connection, usually to port 8333.
DNS Seeds
- The first method is to query DNS using a number of "DNS seeds," which are DNS servers that provide a list of IP addresses of bitcoin nodes. The Bitcoin Core client contains the names of five different DNS seeds.
- In the Bitcoin Core client, the option to use the DNS seeds is controlled by the option switch -dnsseed (set to 1 by default, to use the DNS seed). The command-line argument -seednode can be used to connect to one node just for introductions using it as a seed.
Address Propagation and Discovery
- Once one or more connections are established, the new node will send an addr message containing its own IP address to its neighbors.
- The neighbors will, in turn, forward the addr message to their neighbors, ensuring that the newly connected node becomes well known and better connected.
- Additionally, the newly connected node can send getaddr to the neighbors, asking them to return a list of IP addresses of other peers.
- If there is no traffic on a connection, nodes will periodically send a message to maintain the connection. If a node has not communicated on a connection for more than 90 minutes, it is assumed to be disconnected and a new peer will be sought.
- After bootstrapping, a node will remember its most recent successful peer connections, so that if it is rebooted it can quickly reestablish connections with its former peer network. If none of the former peers respond to its connection request, the node can use the seed nodes to bootstrap again.
Version Message
- Upon establishing a connection, the node will start a "handshake" by transmitting a version message, which contains basic identifying information. The version message is always the first message sent by any peer to another peer.
- The local peer receiving a version message will examine the remote peer’s reported nVersion and decide if the remote peer is compatible. If the remote peer is compatible, the local peer will acknowledge the version message and establish a connection by sending a verack.
Version Message
field information nVersion The bitcoin P2P protocol version the client "speaks" (e.g., 70002) nLocalServices A list of local services supported by the node, currently just NODE_NETWORK nTime The current time addrYou The IP address of the remote node as seen from this node addrMe The IP address of the local node, as discovered by the local node subver A sub-version showing the type of software running on this node (e.g., /Satoshi:0.9.2.1/) BestHeight The block height of this node’s blockchain
net_processing.cpp
void PushNodeVersion(CNode *pnode, CConnman* connman, int64_t nTime)
Class
- CConnman - Connection Manager (net.h)
- CNode - Node (net.h)
- bool fOneShot - This node is added from DNS seed?
- bool fFeeler - This node is being used as a short lived feeler (new address)
- bool fAddnode - This node is added from -addnode
- CAddrMan - Address Manager (addrman.h)
- CNetAddr - IP Address (netaddress.h)
- CService - IP Address + Port (netaddress.h)
- CAddress - A CService with information about it as peer (protocol.h)
- CAddrInfo - Address Information (addrman.h)
Connection Manager
- CConnman::Start (net.cpp)
- AppInitMain (init.cpp)
- AppInit (bitcoind.cpp)
- main (bitcoind.cpp)
- AppInit (bitcoind.cpp)
- AppInitMain (init.cpp)
Thread
- CConnman::ThreadSocketHandler (net.cpp)
- CConnman::ThreadDNSAddressSeed (net.cpp)
- CConnman::ThreadOpenAddedConnections (net.cpp)
- CConnman::ThreadOpenConnections (net.cpp)
- CConnman::ThreadMessageHandler (net.cpp)
ThreadSocketHandler
Loop Send/Receive data to/from peers on port 8333
ThreadDNSAddressSeed
Once Query DNS seeds
ThreadOpenAddedConnections
Loop Retry every 60 seconds if a connection was attempted, otherwise two seconds Add connections from -addnode
ThreadOpenConnections
Loop Open new connections to peers
ThreadMessageHandler
Loop Send/Receive messages
Scheduler
- CConnman::DumpData (net.cpp)
DumpData
Dump addresses to peers.dat and banlist.dat every 15 minutes (900s)
Peer Discovery
DNS seeds
- CMainParams::CMainParams (chainparams.cpp)
