In this post we’ll explore the basics of the bitcoin network, it’s core components, and some of the protocols that the network follows.
Bitcoin is a peer-to-peer (P2P) network of nodes, with no hierarchy or “special” nodes, this means that everyone is at the same level and there isn’t any centralised point of authority. Internet in the early days was like that, a flat network topology of computers interconnected. The Bitcoin network is decentralized by design, the security and trust of the network relies on the interaction between the nodes. Some of these interactions are given by the bitcoin P2P network protocols.
The ‘Extended Bitcoin Network’ is the P2P protocols plus other protocols, such as Stratus that is used for mining and lightweight or mobile wallets. Other protocols can include the pool mining protocols.
A node is any physical device within a network of other devices that’s able to send, receive, and/or forward information. A computer, smartphone or server can all be nodes inside the bitcoin network. A bitcoin node, depending on it’s role on the network, can have more or less functions. All nodes have the routing function included in order to participate in the network, this means that they can discover and connect to other nodes, propagate and validate transactions and blocks. Other nodes depending on their role can have a wallet function, a miner function (mining nodes), a copy of the entire blockchain or run different protocols. Here’s a complete list of the different types of nodes we can have on the bitcoin network:
Let’s see some of these types of nodes and their functions in more detail:
Full nodes, besides their network capabilities, also maintain an up-to-date copy of the entire blockchain, this allows them to autonomously and authoritatively verify any transaction without external reference. These nodes rely on the network to receive updates about new blocks of transactions, which it then verifies and includes in their local blockchain copy. Running a full node may include some requirements such as:
The most common implementation of the software for running a full node is the Bitcoin Core, also known as the ‘Satoshi’ client. More than 75% of the nodes on the bitcoin network run various versions of Bitcoin Core.
These kind of nodes maintain only a subset of the blockchain and verify transactions using a method called Simplified Payment Verification System (“SPV”). They are commonly called lightweight nodes. Some user wallets which run on constrained resource devices like smartphones or tablets, are SPV nodes, and have became the most popular nodes nowadays. Instead of downloading all the blocks like the full nodes, the SPV only download the block headers. The SPV nodes cannot construct the full picture of all UTXO’s that are available for spending, because they don’t have the entire blockchain, instead they use the SPV method to verify transactions which also relies on peers to provide partial views of relevant parts of the blockchain on demand.
It is common to hear that ‘we must wait for six confirmations to really be sure that a transaction went through’, this is because SPV nodes verifies transactions by reference to their depth in the blockchain. This means that an SPV node will create a link between the transaction that it wants to validate and the block that contains it. Then, the node waits until six or more blocks are ‘piled’ on top of the block that contains the transaction. When this happens we can assure that the transaction is valid because all the other nodes in the network did the necessary work to accept the transaction and add more blocks on top ot it. This is a proof that the transaction wasn’t a double spent.
A note to think about with the double spend problem with SPV nodes: A double spend is a situation in which one UTXO’s is used in more than one transaction, hence ‘double spending’ the UTXO. This is a problem solved on the Bitcoin network. Can you get why an SPV can’t verify by itself a double spend and a full node can?
These nodes compete to create new blocks by running specialized hardware to solve the Proof-of-Work algorithm. They can be full nodes with the full copy of the blockchain or lightweight nodes participating in a pool mining and depending on a pool server to maintain a full node.
The Bitcoin relay network is an overlay network that provides additional connectivity between miner nodes. It’s meant to minimize the latency in the transmission of blocks between miners. The speed on which the blocks are distributed through the network is very important for miners, because once a new block is discovered, they must be prepared for the next round of competition to see who mines the next block, so they can’t solely rely on the P2P network for this. The original bitcoin relay network was replaced in 2016 for a new set of protocols called the Fast Internet Bitcoin Relay Engine (FIBRE).
When a new node boots up, it must connect to at least one other node in the network. Usually they connect using a TCP connection on port 8333. In order to achieve this, it must discover the nodes somehow. One method is by querying a list of DNS servers that provide a list of IP addresses of bitcoin nodes. Another way is, when bootstrapping the node a known IP address of an active node is introduced. The node doesn’t have to connect to many peers, it must connect to at least one node connected to other peers in the network, and then it can establish more connections through the first node that it has connected to.
A node doesn’t always have to rely on the same paths for networking functions, it must keep a list of limited, but diverse, connections to different nodes. The paths are not reliable because nodes can go offline, and the node must have a good list of peer connections for working properly and assisting new nodes when they bootstrap.
The first message a node sends after bootstrapping is called the ‘version’ message, and it contains the version of the protocol the node is using, and other useful information to identify the node. When the receiving node receives the version message, it checks if it can support the version of the sender node, and if it can it sends a ‘verack’ message, which is a message acknowledging the node — and then they are connected.
When a new full node starts or goes online, after connecting to the network, the first thing that it must do is update its blockchain database. The first block that it has is the “genesis” block, which is the first node in the blockchain and is embedded in the client’s software. When the starting node sends the ‘version’ message, it also includes the ‘height’ of its blockchain database (number of blocks). The receiving node will see the height and compare it with its own copy of the blockchain. If the number of blocks that the receiver has is higher than the sender, it will know exactly how many nodes the sender is missing. It can send the missing blocks in order to “catch up” with the up-to-date blockchain. There’s a limit of 500 blocks per node connection, so if the number of blocks is higher, the outdated node will have to look for other peers in order to get more blocks.
As you can see, there’s a lot going on with the P2P Bitcoin network, more that we can imagine. I hope you learnt something new and have a bit more understanding of the blockchain!
See you next time!
