Bitcoin Peer to Peer networking & Improvement Proposals
Overview of how the bitcoin peer to peer network works & improvement proposals that address its shortcomings
This aims at providing an overview as to how bitcoin peer-to-peer network works. This article consists of three different parts that discuss different functions of the bitcoin P2P network
- Connecting to a node in the network
- Detecting other nodes in the network
- Receiving Transaction or Block Data
Connecting to a node in the network
When you install a bitcoin node on your computer, there are some hardcoded bitcoin node addresses present in the config which acts as seeder nodes. They are the first peers you connect to in the bitcoin network.
One of the seeder addresses you would find is below, use the dig command to view a list of different IP addresses of bitcoin nodes you can connect to.
$ dig seed.btc.petertodd.orgPrior to connecting to a remote node in the bitcoin network, your local Bitcoin node sends a “PING” to the remote node it wants to connect to and it should respond with a “PONG”. But if the node refuses to respond ( maybe it’s offline ) then the node is “FIRED” i.e disconnected
After a successful connection to a Bitcoin node on the network you perform an initial “Handshake”, this involves the local node initiating the connection sending a version message first and the remote peer sending back its version message, then the initiating peer sends a “Verack” message acknowledging the remote peer version & the remote peer does the same.
The remote peer will not send any data until it receives a version message. The “version” message consists of the version of the bitcoin node you are running.
Detecting other nodes in the network
The way you learn about other bitcoin nodes in the network is by sending “getaddr” messages. After successfully connecting with a remote node, you can send a “getaddr” message to the remote node & it would respond with a sample list of IP addresses of other remote nodes you can connect to.
Also, it continually sends connected node IP addresses to you.
Receiving Transaction or Block Data
After a remote node receives a block or transaction data from the other peers in the bitcoin network it sends an “inv” message to its connecting peers to check if they already have the transaction or block. If the connecting peer doesn’t have it sends a “getdata” response back to the remote node & it responds with the details of the transaction or block.
Bitcoin P2P Networking Improvement Proposals
There are have been various Bitcoin improvement proposals (BIP) to improve the performance of the Bitcoin P2P network. We would review some of them below.
BIP 152 — Compact blocks
This aimed to address decreasing the bandwidth used during block relay between nodes on the bitcoin network.
The protocol is intended to be used in two ways, depending on the peers and bandwidth available. The “high-bandwidth” & “low-bandwidth” mode. In the low-bandwidth mode, peers send new block announcements with the usual inv/headers announcements. And a node without support for compact blocks can still use the legacy block relay protocol.
A compact block contains shortened versions of the transaction ids in a block. The node, when it receives the cmpctblock message, will calculate the shortened txids of all of the transactions that it has in its mempool. It retrieves the transactions that have matching shortened txids from the mempool in order to rebuild the full block. If it cannot find a transaction, it will request it from the peer that sent it the cmpctblock message. In this way the block is relayed without needing to actually send all of the data for the block when the block is relayed; most, if not all, of the transactions in the block will likely be found in the node’s mempool and can be rebuilt from there.
This has been implemented & merged in the bitcoin core codebase. The pull request to the bitcoin core codebase can be found here https://github.com/bitcoin/bitcoin/pull/8068 https://github.com/bitcoin/bitcoin/pull/8393
Graphene — Block Propagation
Graphene is a novel and highly efficient protocol for the transmission of blocks (developed by A. Pinar Ozisik, Gavin Andresen and more) that proposes the use of Bloom filters to identify transactions within a block from the local mempool (short for memory pool, this is the set of all Bitcoin transactions in the network that are awaiting verification and to be included in a block).
It’s an improvement over BIP 152 (Compact blocks). It combines bloom filters & Invertible Bloom Lookup Tables (IBLTs), to reduce the cost of block propagation.
BIP 157 — Client-Side Block Filtering
This BIP describes a new light client protocol in Bitcoin that improves upon currently available options. The light client protocol in use today has known flaws that weaken the security, privacy of clients and allows denial-of-service attack vectors on full nodes.
It describes an alternate protocol for light clients to request data from remote peers in the network that preserves privacy.
Instead of light clients sending a filter to a full node peer, full nodes generate deterministic filters on block data that are served to the client. A light client can then download an entire block if the filter matches the data it is watching for. Since filters are deterministic, they only need to be constructed once and stored on disk, whenever a new block is connected to the chain.
This improves privacy in that blocks can be downloaded from any source so that no one peer gets complete information on the data required by a client. Also, light clients get a better assurance of seeing all relevant transactions because they can check the validity of filters received from peers more easily than they can check the completeness of filtered blocks.
Conclusion
Lots of improvement have been made to how Bitcoin peer to peer networking works. A lot more things are being discussed & researched on as to how to further improve it to make it quite better.
Further Reading
http://cryptoeconomics.cs.umass.edu/graphene/graphene-short.pdf
