Bitcoin pats you on the back. You should master these knowledge points before the bull market.

Written in front:

It has been two months since Bitcoin completed its third "halving", and this period of adaptation has provided opportunities for the outbreak of hot spots such as DeFi and Filecoin, but the real protagonist of the cryptocurrency market has always been Bitcoin. As the speculation wave in the traditional financial market comes to an end, Bitcoin is expected to return to the public's attention. So what knowledge points about Bitcoin do we need to master?

In this article, author Gloria Zhao will introduce the four major types of Bitcoin nodes and describe the P2P connections formed between them, aiming to help everyone better understand the concept of Bitcoin.

This is a beginner-friendly Bitcoin "atlas" that can help you understand the various nodes, software, and participants in the Bitcoin network.

The Bitcoin network is often described as peer-to-peer (P2P), distributed, or decentralized, and is often incorrectly drawn as follows:

In reality, it might look more like this:

So what is a node and what does it do? Is a node a server or a client… or both? Given that there are many different kinds of Bitcoin software, what counts as a node? What are all the participants in Bitcoin (users, miners, nodes, wallets), and how do they interact with each other?

This article draws a diagram of the Bitcoin network that clarifies these definitions and simplifies them. We will classify different types of nodes based on server/client functionality and describe the P2P connections formed between them. Rather than providing statistics for the entire network, this article focuses on enumerating the various possibilities in the network.

The short answer

First, the dots marked with the Bitcoin logo (฿) are nodes in the P2P network, and the edges are the P2P connections between these nodes. In fact, there are many different types of nodes in the Bitcoin network, which can be classified according to their ability to provide services to other peers and clients. Nodes can act as servers, clients, or both at any given point in time.

Node = A participant on a P2P network that implements the Bitcoin P2P protocol. As long as the node follows the Bitcoin protocol, it does not need to run any specific software.

P2P connection = a network connection established directly between two nodes communicating using the Bitcoin P2P protocol. We often use "peer" to refer to other nodes that have a P2P connection with a certain node, also translated as peer nodes.

Node Type

Broadly speaking, nodes are divided into four categories based on the state they maintain and the services they can provide.

1. Full node (also known as full verification node) = a node that can verify transactions and blocks. Full nodes do not search in the block database every time, but retain a certain state, that is, set a UTXO (unused transaction output or "coin").

Therefore, as long as Bitcoin nodes maintain some block metadata and the latest UTXO set, they do not necessarily need a full copy of the blockchain for verification. Pruning nodes implement this exact behavior: they download and process blocks to build the necessary database for verification, and then discard old blocks to save disk space. Because they have all the information and can verify all new blocks and transactions, they are also full nodes.

2. Archive nodes = nodes that have a copy of the entire history of the blockchain. These nodes are able to verify incoming transactions and blocks, as well as query block and transaction data from any point in history, including those that are no longer relevant for verification (hence the name "archive"). The existence of archive nodes is crucial because new nodes need to keep up with the entire history in order to become full nodes. They can only do this by downloading the history one block at a time from archive nodes.

3. Mining nodes = nodes that generate new blocks. This includes maintaining a storage pool (Mempool) of unconfirmed transactions, verifying new transactions, and solving proof-of-work hash puzzles (i.e. finding nonce) to construct blocks. Mining nodes usually use additional hardware (such as Asic miners) to assist them in solving hash puzzles, or participate in mining pools. Technically, there are also some non-full nodes that join mining pools, connect to the full node that manages the mining pool, and help solve PoW puzzles without any verification ( so some mining nodes are not actually full nodes ).

4. Light Client = This node does not retain the full state required for full verification, but trusts other full nodes to do this. A light client may retain a limited amount of data to verify its own transactions, but cannot fully verify all blocks. In Bitcoin Core, "light client" is often synonymous with simplified payment verification (SPV) nodes, but don't confuse it with pruning nodes. In some cases, light clients are not called nodes because they do not perform most of the operations that full nodes usually perform.

Other concepts of nodes

Nodes may also have other characteristics that affect their participation in the network, but they are not mutually exclusive with each other or any of the four categories above. Due to the decentralized nature, and the focus on accessibility in the Bitcoin ecosystem, node operators are free to decide the implementation details and adopt characteristics as long as the node implements the P2P protocol and abides by the consensus rules.

Initial Block Download (IBD) : This is a temporary state in which the node has not yet reached the height of the current block and needs to download old blocks. A full node cannot tell you about transactions without downloading the relevant blocks. The getblockchaininfo RPC will return whether the node is in IBD.

Blocks Only mode : A non-temporary mode in which a full node only validates blocks and the transactions within them, it does not validate any unconfirmed transactions (except its own), does not maintain a mempool, and asks its peers not to relay transactions to it.

Bitcoin Core : This open source software was originally written by Satoshi Nakamoto and is currently maintained by many contributors. You can find the relevant software from bitcoincore.org. It is important to know that Bitcoin Core is not the only software in the Bitcoin P2P network. Some nodes run custom patches that implement specific behaviors, and some nodes may use old versions of Bitcoin Core (which do not incorporate new rules). It is important to recognize which new features require full network cooperation, do not expect nodes to run correctly or honestly, and consider that node operators will be hesitant to upgrade software or will be slow to adopt new software.

Malicious behavior : Any type of behavior that is intended to harm the network (not including vulnerabilities, network complexity, or other unintentional behavior). Bitcoin assumes a highly hostile environment, including the possibility of denial of service attacks, Sybil/eclipse attacks aimed at double spending, spy node attacks attempting to deanonymize addresses, etc.

Node as server

We have seen that each individual node depends on its peers to send the information it needs. In addition, nodes often provide services to many users and client software through non-P2P interfaces such as RPC, HTTP/REST, and GUI.

Some examples of non-Node clients that can use Node as a server:

1. Users running nodes send and receive Bitcoins;

2. Wallets that manage keys, create transactions, and may keep some UTXO state associated with those keys, but do not have a copy of the blockchain and rely on nodes to get the latest information;

3. User-facing software services and applications, such as block explorers, exchanges, and merchants, which query full nodes for information and display it on a web page or application;

4. Developers create nodes in regtest mode to test the functionality or interface itself;

5. Developer-oriented software, such as SDKs, APIs, and other interfaces. For example, the Bitcoin Core CLI (bitcoin-cli) uses the RPC interface to implement the command line interface;

While these connections are not visible to the node’s peers on the P2P network, they nonetheless form an important part of Bitcoin’s functionality. Bitcoin Core developers carefully consider these participants when developing new features or deciding which ones to support.

Now that we understand nodes as servers and clients, here is the view of a single node:

Simplified view of a node

P2P connection type

P2P connections in Bitcoin all speak the "same language" in that they all use the P2P protocol to communicate, but the content of their conversations varies. The Bitcoin Core implementation attempts to balance stability (favoring static connections) and accessibility (encouraging acceptance of connections from new nodes) by facilitating peer discovery and carefully managing connections. Bitcoin Core distinguishes three main types of connections based on how the connection is initiated.

1. Outbound = Automatic connections initiated by nodes through peer discovery. Node discovery starts with getting a list of IP addresses of established nodes, and then is a continuous dynamic process of advertising your own address and trying to connect to addresses you know. Depending on what your node needs (for example in IBD), it can prioritize connections that can provide specific services (such as serving past blocks and transactions).

2. Inbound = Automatic connections initiated by peers (to your peer node). For security reasons, inbound traffic is disabled by default and you need to configure some network and firewall settings to enable it.

3. Manual = A connection that is established manually (e.g. via CLI or RPC). You might create a manual connection if you need to connect to a node operated by someone you trust, or if you are testing software and need to control these connections.

Other concepts of P2P connection

1. Diversity of outbound connections

Outbound connections can be broken down into further categories based on the information received and the duration of the connection.

Full-Relay outbound connections expect to communicate everything, including blocks, transactions, and addresses (used to find peers, similar to IP addresses, and not to be confused with wallet addresses used in transactions). Block-Only-Relay outbound connections only expect to receive blocks, not to be confused with blocks-only mode. It is perfectly normal for a full node to have block-only-relay connections to 1-2 peers, and full-relay connections to everyone else.

One-Shot and Feelers are temporary outbound connections used for node discovery. One-Shot connections are used to request a list of addresses that can be used to find new peers. Feelers connections are used to verify that an address corresponds to an actual node.

2. Individual differences

As we can see, each node may provide different services and look for specific information from its peers. Each connection starts with a version handshake, where the node sends information about itself (such as the best block height) and negotiates what to talk about (such as only interested in blocks). The connection may also change through subsequent messages (such as fee filter messages) to indicate that they are only interested in relaying transactions with the lowest fee rate.

3. Discourage, disconnect and ban

Bitcoin Core nodes track peer behavior that indicates they may be malicious or running faulty software. In response to such behavior, nodes may choose to block (flag it for misbehavior and potentially disconnect in favor of new peers), disconnect, or ban the peer.

4. Permissions and whitelists

Nodes can also maintain a list of permissions each peer has, such as specific services it is allowed to request, or tolerance for misbehavior that would normally be penalized. Allowed misbehavior is often added manually for custom personal light clients, and nodes operated by people who trust each other. Specific IP addresses can also be whitelisted by the node in question.

5. The importance of asymmetry

Note that each individual connection is bidirectional, but they are asymmetric: the initiating peer may understand the connection as a [full-relay] outbound, block-relay-only, feeler, or one-shot connection, but the receiving peer only sees an inbound connection with certain established rules. This hides information about whether a node's behavior reveals its internal mechanisms or simply reflects the nature of the connection through ambiguity.

For example, if a node knows that its peer is in blocksonly mode (i.e. rejecting all incoming transaction messages), then it is clear that all transactions sent from that peer correspond to its own wallet address. In contrast, the receiving node only sees inbound connections that have transaction relaying turned off.

This could mean blocksonly mode, a block relay-only connection, or a feature of the connection. A more detailed view of a single node is shown below ( note that the direction of the arrows only indicates which node initiated it, not that the communication is non-bidirectional ):

A slightly more complete view of the node

The “complete” map

Each node has limited information about the entire network. Nodes actually only see their own peers, and peers may lie about what type of node they are . In the event of an eclipse attack, all peers may even come from the same person. This is an advantage for privacy and security because it applies to adversaries as well. Limited information makes targeted attacks more difficult. By creating a large number of temporary connections, it is possible to gather approximate information about how many nodes are in the network, but this information is far from comprehensive.

For example, it is not immediately apparent on the network whether a node is participating in a mining pool. Some websites are able to generate analyses of computing power ratios by roughly understanding which nodes are part of a mining pool and observing how many blocks they have “mined.” However, they can be misleading because groups of nodes or even multiple mining pools may be operated by a single entity.

To sum up, we can imagine this simplified network diagram:

Simplified Bitcoin network diagram

This diagram shows the possibilities without showing the size of the network (which is very large) or the topology (which is dynamic and unknown). Note that the possibilities include:

1. A Bitcoin Core full node with various clients connected through a non-P2P interface. For example, a user downloads the software from bitcoincore.org and uses the command line or GUI to send and receive coins.

2. Lightweight clients do their best to connect to various full nodes in order to provide services to their clients.

3. A full node that serves one or more light clients, perhaps a Bitcoin enthusiast who uses some cloud provider to run a full node on his personal device and uses an even lighter application.

4. A custom full node (e.g., a mining pool manager) connected to a set of custom light clients (e.g., individual mining pool participants) via the P2P network and some private network.

in conclusion

Hopefully this post has helped clarify what people mean by “node” and “P2P network” and connected the dots on how all the participants in a network interact with each other. I hope it has also provided some insight into how Bitcoin Core implements peer-to-peer connectivity for privacy, and how to enable new nodes to participate. Thanks for reading!

Many thanks to John Newbery and Amiti Uttarwar for helping me understand and document this information.

Link to this article: https://www.8btc.com/article/622968
Please indicate the source of the article when reprinting