Network Paradox of Bitcoin
👷‍♂️ Software Architecture Series — Part 28
Bitcoin is a de-centralized digital currency which operates on a peer-to-peer distributed network based on Blockchain. In this de-centralized yet distributed setting, each node is treated equally. There is no concept of hierarchy or master-slave architecture. Nodes can leave and join the system at will and there is no central point of failure. Interestingly this whole network runs on internet using TCP/IP protocol.
Although there is no central authority in Bitcoin, the nodes can be full or lightweight nodes. The full nodes have routing capability and the ability to perform all the permissible activities within Bitcoin network, which includes mining and broadcasting transactions as well as providing wallet services. Whereas the lightweight nodes do not have the ability to mine new blocks but can verify transactions using Simplified Payment Verification. To become a lightweight node, it is not required to download entire blockchain database. These are lightweight as the name suggests and vast majority of nodes in the Bitcoin network are lightweight nodes only. They consume fewer resources than full nodes. Rather than maintaining entire blockchain database, lightweight nodes maintain only block headers. This makes them suitable for devices with limited computing power, such as mobile phones or hardware wallets.
Lightweight nodes can verify transactions using Merkel proofs, which provide a cryptographic proof that the transaction is part of a specific block without requiring the node to download the entire block. However, lightweight nodes are not as secure as full nodes because they do not independently validate transactions or enforce consensus rules. They reveal their transaction history to the full nodes they connect to, which can potentially compromise user privacy.
It must be noted here that there is distinction between transaction verification and validation in Bitcoin network. Transaction verification is the process of ensuring that a transaction is properly formatted and meets the basic requirements for inclusion in a block. This includes verifying that the transaction adheres to the rules of the blockchain protocol, such as having valid inputs, outputs, signatures, and transaction fees. Simply put, transaction verification process confirms that a transaction is correctly constructed and can be included in a block according to the protocol’s rules.
Whereas transaction validation is about confirming that a transaction is not only correctly formatted but also conforms to all the consensus rules of the blockchain network. The validation process requires verifying that the transaction’s inputs are unspent (UTXOs), that the sender has sufficient funds to cover the transaction amount, and that the transaction does not violate any protocol rules, such as double-spending or invalid signatures.
So, if a node wants to join the Bitcoin network, how would it contact the network as there is no central authority here. Moreover, nodes which are part of the network can join and exit at will, which makes the setting quite dynamic. Nodes can be located in different geographic locations with their public facing IP address. So, how does a node which wants to join the network figures out its peers? There is no central server somewhere to respond to their request the way a typical Internet-based web application works. Here is what happens behind the scenes.
Any node which wants to join the Bitcoin network has to first get access to Bitcoin Core or Bitcoin J program on their system. These programs come hardcoded with DNS seeds, which are maintained by Bitcoin community members. The DNS seeds have several host names hardcoded in the system that resolve to a list of IP addresses that are running the Bitcoin nodes. When these DNS seeds are queried, the look up response includes one or more records with the IP addresses of full nodes that may accept new incoming connections.
Once a bitcoin connection is active, it gets easier pull the list of other Bitcoin nodes active at that point in time. Although only one peer may be enough to bootstrap the connection of a node to the Bitcoin network; the fresh node must continue to discover and connect to new peers as nodes come and go at will and connections cannot be deemed stable. However, it is possible for some of active nodes to not be aware of each and every Bitcoin node in the network at any time. But active nodes must have port numbers of the other Bitcoin connections they are aware of, because once TCP packets reach their destination, port numbers are required by the OS to direct the message to correct application on the system.
