The Bitcoin Network

---

The Bitcoin network operates as a peer-to-peer (P2P) system where nodes engage in transaction activities. These nodes are responsible for verifying and disseminating transactions and blocks. Among them, miners are specialized nodes that create new blocks. The network comprises various types of nodes, with the two primary categories being full nodes and simple payment verification (SPV) nodes.

Full nodes, which utilize Bitcoin Core client software, handle wallet functions, mining, complete blockchain storage, and network routing. However, not every node in the Bitcoin network is required to execute all these roles. SPV nodes, or lightweight clients, focus solely on wallet operations and network routing.

Identify a Bitcoin Network

The Bitcoin network is distinguished by its unique magic value, which serves to signify the originating network of a message. The subsequent table presents a compilation of these values −

A full Bitcoin node performs four functions. These are wallet, miner, blockchain and network routing. We have already discussed mining and blockchains in the previous chapters. Here, we continue where we left off, with the bitcoin network.

Protocol Messages in Bitcoin Network

There are currently some distinct types of protocol messages, with the potential for this number to grow as the protocol evolves. Below is a list of the most frequently utilized protocol messages along with their descriptions −

• Version − This initial message is sent by a node to the network, indicating its version and block count. The remote node responds with the same details, establishing the connection.
• Verack − This message acknowledges the version message and accepts the connection request.
• Inv − Nodes use this message to announce their awareness of blocks and transactions.
• Getdata − This message is a response to an inv, requesting a specific block or transaction identified by its hash.
• Getblocks − This returns an inv packet that includes a list of all blocks starting from the last known hash or up to 500 blocks.
• Getheaders − This message requests block headers within a specified range.
• Tx − This is used to transmit a transaction in response to the getdata protocol message.
• Block − This message sends a block in reply to the getdata protocol message.
• Headers − This packet can return up to 2,000 block headers as a response to the getheaders request.
• Getaddr − This message is sent to request information about known peers.
• Addr − This provides details about nodes on the network, including the number of addresses and a list of addresses formatted as IP address and port number.
• Ping − This message is utilized to verify the activity of the TCP/IP network connection.
• Pong − This message serves as a response to a ping, confirming that the network connection is operational.

What Happens in a Bitcoin Network?

The process of transmission of message via protocols is performed in a bitcoin network. This occurs in a chronological order, which is given below −

• In the bitcoin network, the process starts when the client transmits a protocol message known as a version message, which includes several fields such as version, services, timestamp, network address, nonce, and additional information.
• In response, the remote node sends its own version message, followed by an exchange of verack messages between both nodes, confirming that the connection has been successfully established.
• Subsequently, getaddr and addr messages are exchanged to identify peers that the client is not already aware of.
• During this process, either node may send a ping message to verify the ongoing status of the connection. The getaddr and addr message types are specified within the Bitcoin protocol.

This network protocol sequence diagram illustrates the communication between two Bitcoin nodes during the initial connection phase.

In the given example, Node A is positioned on the left, while Node B is on the right. Node A initiates the connection by sending a version message that includes the version number and the current timestamp to the remote peer, Node B. Node B then replies with its own version message, which also contains the version number and current time.

Following this, Node A and Node B exchange verack messages, signifying that the connection has been successfully established. Once the connection is confirmed, the peers can exchange getaddr and addr messages to discover additional peers within the network.

At this point, the process of downloading blocks can commence. If the node has already synchronized all blocks, it will listen for new blocks using the inv protocol message. If not, it first checks for responses to inv messages and whether it possesses inventories. If inventories are available, it will request the blocks using the getdata protocol message; if not, it will request inventories through the getblocks message.

Full Client and SPV Client

The Bitcoin network nodes can function in two primary modes: as full clients or as lightweight SPV clients. Full clients, also known as thick clients or full nodes, download the entire blockchain, providing the highest level of security for validating transactions.

In contrast, SPV clients allow users to verify payments without the need to download the complete blockchain. These SPV nodes maintain only the block headers of the longest valid blockchain. Verification is achieved by examining the Merkle branch, which connects transactions to the original block in which they were recorded. This method can be somewhat impractical, necessitating a more efficient solution, which was introduced through BIP37.

Bloom Filters

A bloom filter is a specialized data structure, specifically a bit vector with indexed positions, designed to probabilistically assess the membership of an element. It allows for probabilistic lookups that may yield false positives but guarantees no false negatives. This implies that while the filter may incorrectly indicate that an element is part of the tested set, it will never falsely claim that an existing element is absent. In essence, false positives can occur, but false negatives are impossible.

To incorporate elements into the bloom filter, they are hashed multiple times, and the corresponding bits in the bit vector are set to 1 based on the resulting indices. To verify the presence of an element, the same hash functions are applied, and the bits in the bit vector are checked to see if they are all set to 1.

Bloom filters are primarily utilized by simple payment verification (SPV) clients to request specific transactions and the associated Merkle blocks.

A Merkle block serves as a compact representation of a block, containing a block header, several hashes, a list of 1-bit flags, and a transaction count. This data can be utilized to construct a Merkle tree. The filter is tailored to match only those transactions and blocks that the SPV client has requested. After exchanging version messages and establishing a connection between peers, nodes can configure filters based on their specific needs.