Bitcoin Network

Bitcoin is structured as a peer-to-peer network architecture on top of the Internet. The network nodes interconnect in a mesh network with a “flat” topology. There is no server, no centralized service, and no hierarchy within the network.

• Decentralization of control is a core design principle that can only be achieved and maintained by a flat, decentralized P2P consensus network.
• Although nodes in the bitcoin P2P network are equal, they may take on different roles depending on the functionality they are supporting.
• A set of rules for independent transaction validation and currency issuance (consensus rules)
• A bitcoin node is a collection of functions: routing, the blockchain database, mining, and wallet service.

Mining nodes compete to create new blocks by running specialized hardware to solve the Proof-Of-Work algorithm.

The main bitcoin network, running the bitcoin P2P protocol, consists of between 5,000 and 8,000 listening nodes running various versions of the bitcoin reference client (Bitcoin Core) and a few hundred nodes running other implementations of the bitcoin P2P protocol, such as Bitcoin Classic.

Large companies utilize Bitcoin Core client-based full-node clients to interface with the bitcoin network. These nodes serve as network edge routers, enabling the development of services like exchanges, wallets, and block explorers. They maintain full copies of the blockchain and facilitate interactions with the network, without engaging in mining or wallet functions.

Stratum Network

• Stratum network in Bitcoin is a communication protocol used by miners to connect to mining pools and participate in the process of mining new blocks efficiently.
• It enables miners to receive mining jobs and submit block solutions for verification and inclusion in the blockchain.
• The Stratum protocol operates over TCP/IP and has become the standard method for mining pool communication in Bitcoin and several other cryptocurrencies. It helps streamline the mining process, improve efficiency, and distribute rewards among participating miners in a fair manner.

Bitcoin Relay Networks

A bitcoin relay network is a network that attempts to minimize the latency in the transmission of blockers between miners.

Bitcoin miners are engaged in a time-sensitive competition to solve the Proof-Of-Work problem and extend the blockchain. While participating in this competition, they must minimize the time between the propagation of a winning block and the beginning of the next round of competition.

• 2015: Matt Carallo created the original Bitcoin Relay Network to enable fast synchronization of blocks between miners using several specialized nodes hosted on AWS.
• 2016: It was replaced by Fast Internet Bitcoin Relay Engine (FIBRE) also created by Matt Carallo.
• Falcon (WIP).

They are like freeways (shortcuts between two points with heavy traffic), not a replacement for bitcoin’s P2P network.

Network Discovery

When a new node boots up, it must discover other bitcoin nodes on the network in order to participate. To connect to a known peer, nodes establish a TCP connection, usually to port 8333. Upon establishing a connection, the node will start a “handshake” by transmitting a version message, which contains basic identifying information, including:

• nVersion: the bitcoin P2P protocol version the client “speaks” (e.g. 70002)
• nLocalServices: a list of services supported by the node, (NODE_NETWORK)
• nTime: the current time
• nVersion: the bitcoin P2P protocol version the client “speaks” (e.g. 70002)
• addrYou: the IP address of the remote node as seen from this node
• addrMe: the IP address of the local node
• nVersion: the bitcoin P2P protocol version the client “speaks” (e.g. 70002)
• subver: a subversion 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.

If the remote peer is compatible, the local peer will acknowledge the version message and establish a connection by sending a verack.

How does a new node find peers? 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. Once one or more connections are established, the new node will send an addr message containing its own IP address to its neighbors, ensuring the newly connected node becomes well known and better connected.

Paths are not reliable–nodes come and go–and so the node must continue to discover new nodes as it loses old connections as well as assist other nodes when they bootstrap.

Full Nodes

• Full nodes are nodes that maintain a full blockchain with all 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.
• A full blockchain node can independently and authoritatively verify any transaction without recourse or reliance on any other node or source of information.
• Running a full blockchain node gives you the pure bitcoin experience: independent verification of all transactions without the need to rely on, or trust, any other systems.
• The process of syncing the blockchain starts with the version message, because that contains BestHeight, a node’s current blockchain height. A node will see the version messages from its peers, and know how many blocks they each have, and be able to compare to how many blocks it has in its own blockchain.
• Nodes compare their blockchain height with their peers to identify which blocks are needed to catch up.
• The longer blockchain peer shares the hashes of the first 500 blocks to be transmitted using an inv (inventory) message.

Simplified Payment Verification (SPV) Nodes

Not all nodes have the ability to store the full blockchain, (smartphones, tablets, or embedded systems). As bitcoin adoption surges, the SPV node is becoming the most common form of bitcoin node, especially for bitcoin wallets.

The resulting chain of blocks, without transactions, is 1,000 times smaller than the full blockchain. SPV nodes cannot construct a full picture of all the UTXOs that are available for spending because they do not know about all the transactions on the network.

SPV nodes verify transactions using a slightly different methodology that relies on peers to provide partial views of relevant parts of the blockchain on demand.

For e.g., When examining a transaction in block 300,000, a full node links all 300,000 blocks down to the genesis block and builds a full database of UTXO, establishing the validity of the transaction by confirming that the UTXO remains unspent. An SPV node cannot validate whether the UTXO is unspent. Instead, the SPV node will establish a link between the transaction and the block that contains it, using a merkle path.Then, the SPV node waits until it sees the six blocks 300,001 through 300,006 piled on top of the block containing the transaction and verified it by establishing its depth under blocks 300,006 to 300,000. The fact that other nodes on the network accepted block 300,000 and then did the necessary work to produce six more blocks on top of it is proof, by proxy, that the transaction was not a double spend.

(That is why Binance waits for some x amount of block confirmation from the network, since it doesn’t have the complete picture as it is an SPV node and not a full node).

• The SPV node establishes the existence of a transaction in a block by requesting a merkle path proof and by validating the Proof-Of-Work in the chain of blocks.
• The SPV nodes are vulnerable to network partitioning attacks or Sybil attacks, where they are connected to fake nodes or fake networks and do not have access to honest nodes or the real bitcoin network.

Unlike full blockchain nodes, which collect all transactions within each block, the SPV node’s requests for specific data can inadvertently reveal the addresses in their wallet. To protect user’s privacy, bitcoin developers added a feature called bloom filters.

Transaction Pools

• TNodes on the bitcoin network maintain a temporary list of unconfirmed transactions known as the mempool or transaction pool.
• The mempool keeps track of transactions that are known to the network but not yet included in the blockchain.
• Wallet nodes, like Binance, use the transaction pool to track incoming payments that have been received but are not yet confirmed.
• Some node implementations also have a separate pool for orphaned transactions.
• Orphan transactions are temporarily stored in the orphan pool if their input refers to a missing parent transaction.
• The orphaned transactions remain in the pool until the parent transaction arrives.