Posted on Leave a comment

Sniff the Bitcoin network

Sniff Bitcoin Network

Out of curiosity we are going to listen to the network traffic between my full node and the rest of the Bitcoin network. As what interests me is to know the normal traffic commands, I will not execute any protocol command and I will have the sniffer acting until a new block is generated.

For this we will use the tcpdump tool on the Bitcoin full node BCubium that allows us to capture the network traffic on the specific communication port. In our case, as the node is running Tor, we will activate listening on port 9050 and on the loopback network interface.

The command to execute is the following:

tcpdump -i lo -s 65535 port 9050 -w /mnt/disk/tmp/BCubium_net_20200912.dump 

We inspect the file generated with the Wireshark utility.

We find the types of messages sent: addr, getdata, headers, inv, ping, pong and tx.

addr

Provides information about known nodes on the network. If the nodes are not advertised they are forgotten after 3 hours.

inv

Allows a node to report the existence of one or more objects. It can be received without requesting it or in response to a getblocks type message.

getdata

Used in response to an inv message to retrieve the content of a specific object. Usually getdata is sent after receiving the inv packet, after filtering known objects. It can be used to retrieve transactions.

headers

This message is sent in response to the getheader message that returns the desired block headers.

ping

Message to test the liveliness of the TCP / IP connection. Any connection error is assumed to be a closed connection and the address is removed as the current pair.

pong

Response message to a ping message by a node to demonstrate its liveliness on the network. 

tx

Describes a bitcoin transaction, in response to getdata.

version

When a node creates an outbound connection, it immediately announces its version.

verack

Themessage is sent in response to the version. It consists only of a message header with the command string “verack”.

There is more information about the Bitcoin protocol on the page, Protocol documentation

One aspect that has surprised me is the fact that although we have been listening to the network for well over 10 minutes, no complete block has been received, I suppose it will be because in practice the entire blocks will not be sent with all their transactions, but rather the references to these so that from them they are taken from the mempool and assemble the block, thereby achieving a very important saving in the volume of network traffic.