Posted on Leave a comment

Escuchando la red P2P de Bitcoin

Sniff Bitcoin Network

Por curiosidad vamos a escuchar el tráfico de red que hay entre mi full node y el resto de la red de Bitcoin. Como lo que me interesa es conocer los comandos de tráfico normal no ejecutaré ningún comando del protocolo y tendré el sniffer actuando hasta que se genere un bloque nuevo.

Para ello utilizaremos la herramienta tcpdump sobre el Bitcoin full node BCubium que nos permite capturar el tráfico de red sobre el puerto de comunicación en concreto. En nuestro caso como el nodo se está ejecutando Tor activaremos la escucha en el puerto 9050 y en el interfaz de red de loopback.

El comando a ejecutar es el siguiente:

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

Inspeccionamos el fichero generado con la utilidad Wireshark.

Nos encontramos los tipos de mensajes enviados: addr, getdata, headers, inv, ping, pong y tx.

addr

Proporciona información sobre los nodos conocidos de la red. Si los nodos no se anuncian se olvidan después de 3 horas.

inv

Permite a un nodo avisar de la existencia de uno o más objetos. Se puede recibir sin solicitarlo o en respuesta a un mensaje de tipo getblocks.

getdata

Se usa en respuesta a un mensaje inv para recuperar el contenido de un objeto específico. Por lo general, getdata se envía después de recibir el paquete inv, después de filtrar objetos conocidos. Se puede utilizar para recuperar transacciones.

headers

Este mensaje se envía en respuesta al mensaje getheader que devuelve los encabezados de bloque deseados.

ping

Mensaje para probar la vivacidad de la conexión TCP / IP. Se presupone que cualquier error de conexión es una conexión cerrada y la dirección se elimina como par actual.

pong

Mensaje de respuesta a un mensaje de ping por un nodo para demostrar su vivacidad en la red. 

tx

Describe una transacción de bitcoin, en respuesta a getdata.

version

Cuando un nodo crea una conexión saliente, inmediatamente anuncia su versión.

verack

El mensaje verack se envía en respuesta a la versión. Consta únicamente de un encabezado de mensaje con la cadena de comando “verack”.

Hay más información sobre el protocolo de Bitcoin en la página, Protocol documentation

Traducción del artículo Sniff the Bitcoin network

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

Posted on Leave a comment

Bitcoin Core update script to version 0.20.0

The Script executed BCubium the BGeometrics full node Bitcoin to update the Bitcoin Core software to the new version 0.20.0

#/bin/bash

VERSION=0.20.0
PATH_BITCOIN=/var/lib/bitcoin
PATH_BITCOIN_INSTALL=/usr/bin
USER_BITCOIN=bitcoin
PROCESS_DEP_BITCOIN="bitcoind lnd rtl btc-rpc-explorer"

if [ -n "$1" ]; then
    VERSION=$1
fi

systemctl stop $PROCESS_DEP_BITCOIN
su -c "wget https://bitnodes.io/install-full-node.sh" $USER_BITCOIN
su -c "sed -i "s/VERSION=.*/VERSION=$VERSION/g" install-full-node.sh" $USER_BITCOIN
su -c "bash install-full-node.sh" $USER_BITCOIN
su -c "$PATH_BITCOIN/bitcoin-core/bin/stop.sh" $USER_BITCOIN
install -m 0755 -o root -g root -t $PATH_BITCOIN_INSTALL $PATH_BITCOIN/bitcoin-core/bin/bitcoin*
systemctl start $PROCESS_DEP_BITCOIN
rm -fr $PATH_BITCOIN/bitcoin-core/
rm -f install-full-node.sh
$PATH_BITCOIN_INSTALL/bitcoind --version | grep version

In Github: bitcoin-core_update.sh

Posted on Leave a comment

¿Valen las tarjetas MicroSD para almacenar la Blockchain?

Esta es la pregunta que más nos habéis hecho con diferencia así que vamos a contestarla.

Las tarjetas MicroSD tienen mala fama para el almacenaje de la información a largo tiempo, esto viene debido a las tarjetas antiguas que tenían un límite bajo de escrituras y a las tarjetas de baja gama que son muy baratas pero que tienen índices de fallo alto, solo hay que revisar los comentarios en las webs de ventas de estas tarjetas, pero las tarjetas actuales y de calidad son válidas para almacenar información a largo plazo.

En el caso de BCubium la tarjeta que viene es de alta alta gama, sólo utilizamos dos tarjetas

Samsung Memory MB-MC512GAEU – Micro SD de 512 GB Evo plus  

Lexar High-Performance 512GB 633x microSDXC UHS-I

Estas tarjetas que cuestan entre 4 y 5 veces más que las de baja gama y tienen muy buenas referencias por parte de los consumidores.

Tanto Samsung como Lexar dan una garantía de 10 años para estas tarjetas.

Estas microSD normalmente se utilizan en cámaras de vídeo y de fotografía donde el volumen de escritura es muy alto y responden muy bien.

En nuestro caso el sistema operativo está en la memoria eMMC de la placa base NanoPI Neo Plus 2 y la tarjeta MicroSD se utiliza para almacenar la Blockchain y ya viene precargada desde nuestro laboratorio así que los ratios de lectura y escritura son los debidos a la operativa derivada de la escritura de los bloques cada 10 minutos (aprox.), el indexado de las transacciones y la comunicación entre los distintos full nodes de la red. Está funcionalidad conlleva un número medio de lecturas de la tarjeta y un número muy bajo de escrituras lo cual significa que la tarjeta sufre muy poco porque lo que más le afecta a las microSD es la escritura de información.

Escogiendo un día al azar el ratio medio de io por segundo es 742 kB de lectura y sólo 53 kB de escritura.

También podemos observarlo al momento ejecutando la herramienta dstat, obteniendo valores similares:

Así que realizando la funcionalidad de full node de Bitcoin más un Lightning Network Daemon como se hace en BCubium tenemos un ratio medio de lecturas y muy bajo de escrituras las tarjetas microSD de gama alta son un dispositivo totalmente válido para el almacenaje con seguridad a corto, medio y largo plazo. Comentar que en la microSD no se guarda la información personal del nodo sólo se almacena la Blockchain por lo que si se estropease se podría introducir otra tarjeta y resincronizar el histórico de Bitcoin.

La versión del artículo en inglés “Are MicroSD cards worth to store the Blockchain of Bitcoin?“.

Posted on Leave a comment

Why don’t we use Docker in BCubium full node

Docker is a virtualization technology that allows the packaging of an application along with all its dependencies and libraries in one container. This resulting software container can be run on machines other than where it was created with the sole premise that they have the Docker containerization system.

Containerization technology is more efficient than virtualization of the entire operating system because it does not need to replicate the entire system but only what is necessary for the execution of the container. Docker uses Linux cgroups technology to manage container resources and achieve isolation between them.

The main advantages that containerization offers us are the following:

It provides consistency, since it contains both the application code and the libraries it uses, whether they are its own or those of third parties, plus the complete execution environment, for example in a Java application we would have the developed code, plus all the libraries it uses, plus the complete application server. Much fewer points of failure when running the application.

We achieve standardization and productivity, by using the same image for all environments, development, integration, quality, pre-production, production or whatever it is, it is easier for us to manage it, label it, make backups, rollbacks … It 

helps in continuous integration and application of the DevOps philosophy because it facilitates the automated execution of tests on the software and the promotion among the different existing environments.

It improves security by having separate and isolated containers since if an intruder compromises the application that runs inside a container, its scope is limited to that container and not to the entire system.

It is multi cloud, since in all public and private clouds they have environments that allow the execution of Docker containers.

On the other hand, as the number of containers grows, a system that manages and automates operations with them begins to be needed, which is why platforms such as Kubernetes, Rancher, Openshift appeared …

With containers and the platform for their management, the Greater advantage provided by this technological system, which is dynamic autoscaling depending on the load, very useful for large websites with many visits and with an irregular load. I explain it with an example, if we have a web application of a company where the number of visits is different depending on the time of day, the day of the month or the month of the year, which is normal, with containerization technology we can configure that when the system load grows and exceeds a certain threshold, new containers are installed to absorb this increase in demand and when that load decreases, the created containers are eliminated, thereby using only the necessary resources at all times and thus reducing the cost hardware provisioning.

So far everything very nice but … what do we have in most of the Bitcoin full nodes?

A basic hardware to run a full node along with other applications to extend functionality and facilitate management, are usually basic boards with a processor with few resources, with little CPU and with little RAM. In the case of BCubium even more because our hardware is very limited because we want to have a small node and we are running bitcoin-core, LND, BTC-RPC-Explorer, RTL, the node administration website and some other tool, and We do not see any gain for running it with Docker because:

The applications that are run have been developed by third parties, they already give them fully functional, they install without problems without the need to containerize them.

When they are already installed, they automatically incorporate all the libraries they need and those they need from the Linux operating system with their package system, allowing them to self-install.

We are not going to make modifications to these applications, that is, they are not going to have a development made by us, so I do not have to run any continuous integration system, test batteries, or promotion between environments.

The fact of executing them containerized supposes an extra consumption of resources since each container comes with its own operating system plus the tools that the container management needs, plus the libraries necessary for its execution, causing it to have duplicate libraries and tools in the different containers and in the end forces us to have a system with more powerful hardware when what we want is just the opposite, a minimal system.

For our part, at BGeometrics we carry out a development that is the node administration website, which is a small website, so there is no great profit for developing it using containers and we also have a set of scripts that use many applications and utilities of the operating system and It does not matter that they run in an isolated container because it would mean having to install all these tools in the containers and some of them need to have access to the guest operating system.

Docker execution complicates management as we now have, in addition to having to perform the operation of the installed software, we must monitor the execution of each container and the communications between them, which among other things means that we have to have another network interface in the system. . 

In our case, our system runs on a motherboard and a processor, and we have no interest in running it on a public cloud, so we lose the ease that migration containers bring to the cloud.

There is no point in dynamic autoscaling which is the great advantage of containerization since you are not going to install a system like Kubernetes when we have a few containers, the load is very low and constant and access to applications like BTC-RPC-Explorer or RTL is done very occasionally and by a single person …

Summarizing Docker is a great technology that is already here and will continue with us for a long time, if we add to that the orchestrators like Kubernetes and on these Ranchers, Openshift … we have the complete kit to achieve a customized dimensioning, but in a case like ours where what we want is to run software on minimal hardware we do not need those advantages and we avoid adding complexity to the system and having a greater consumption of resources.

Posted on Leave a comment

Por qué no utilizamos Docker en BCubium full node

Docker es una tecnología de virtualización que permite el empaquetado de una aplicación junto con todas sus dependencias y librerías en un contenedor. Este contenedor de software resultante puede ejecutarse en otras máquinas distintas a donde se creó con la única premisa que tengan el sistema de contenerización de Docker.

La tecnología de contenerización es más eficiente que la de virtualización del sistema operativo completo porque no necesita replicar todo el sistema sino únicamente lo necesario para la ejecución del contenedor. Docker utiliza la tecnología cgroups de Linux para gestionar los recursos de los contenedores y conseguir el aislamiento entre ellos.

Las principales ventajas que nos ofrece la contenerización son las siguientes:

Aporta consistencia, al contener tanto el código de la aplicación como las librerías que utiliza, ya sean propias o de terceros, más el entorno completo de ejecución por ejemplo en una aplicación Java tendríamos el código desarrollado, más todas las librerías que utiliza, más el servidor de aplicaciones completo. Muchos menos puntos de fallo a la hora de ejecutar la aplicación.

Conseguimos estandarización y productividad, al utilizar la misma imagen para todos los entornos, desarrollo, integración, calidad, preproducción, producción o los que haya nos es más sencillo gestionarla, etiquetarla, hacer backups, rollbacks… 

Ayuda en la Integración continua y la aplicación de la filosofía DevOps porque facilita la ejecución automatizada de pruebas sobre el software y la promoción entre los distintos entornos existentes.

Mejora la seguridad al tener contenedores independientes y aislados ya que si un intruso compromete la aplicación que se ejecuta dentro de un contenedor su ámbito de acción se limita a ese contenedor y no a todo el sistema.

Es multi cloud, ya que en todos los clouds públicos y privados tienen entornos que permiten la ejecución de contenedores Docker.

Por contra a medida que el número de contenedores crece se empieza a necesitar un sistema que gestione y automatice las operación con estos y por ello aparecieron plataformas como Kubernetes, Rancher, Openshift…

Con los contenedores más la plataforma para su gestión se consigue la mayor ventaja que nos aporta este sistema tecnológico que es el autoescalado dinámico en función de la carga, muy útil para websites grandes con muchísimas visitas y con una carga irregular. Lo explico con un ejemplo, si tenemos una aplicación web de una empresa donde el número de visitas sea distinto en función de la hora del día, del día del mes o del mes del año, que es lo normal, con la tecnología de contenerización podemos configurar que cuando la carga del sistema crezca y supere un determinado umbral se instancien nuevos contenedores para absorber ese aumento de la demanda y cuando esa carga decrezca se eliminen los contenedores creados consiguiendo con ello utilizar sólo los recursos necesarios en cada momento y así reducir el coste del aprovisionamiento de hardware.

Hasta ahora todo muy bonito pero… ¿qué tenemos en la mayor parte de los Bitcoin full nodes?

Un hardware básico para ejecutar un full node junto con otras aplicaciones para ampliar funcionalidad y facilitar la gestión, normalmente son placas básicas con un procesador con pocos recursos, con poca CPU y con poca RAM. En el caso de BCubium todavía más porque nuestro hardware es muy limitado porque queremos tener un nodo pequeño y en él estamos ejecutando bitcoin-core, LND, BTC-RPC-Explorer, RTL, la web de administración del nodo y alguna herramienta más, y no vemos ninguna ganancia por ejecutarlo con Docker por:

Las aplicaciones que se ejecutan han sido desarrolladas por terceros, ya nos las dan totalmente funcionales, se instalan sin problemas sin necesidad de contenerizarlas.

Cuando se instalan ya auto incorporan todas las librerías que necesitan y las que necesitan del sistema operativo Linux con su sistema de paquetes permite que se autoinstalen.

No vamos a hacer modificaciones sobre estas aplicaciones es decir no van a tener un desarrollo hecho por nosotros por lo que no tengo que ejecutar ningún sistema de integración continua, ni baterías de pruebas, ni promoción entre entornos.

El hecho de ejecutarlas contenerizadas supone un consumo extra de recursos ya que cada contenedor viene con su propio sistema operativo más las herramientas que necesita la gestión de los contenedores, más las librerías necesarias para su ejecución, lo provoca que tenga librerías y herramientas duplicadas en los distintos contenedores y al final nos obliga a tener un sistema con un hardware más potente cuando lo que queremos es justo lo contrario, un sistema mínimo.

Por nuestra parte desde BGeometrics realizamos un desarrollo que es la web de administración del nodo que es un website pequeño por lo que no hay una gran ganancia por desarrollarlo utilizando contenedores y también tenemos un conjunto de scripts que utilizan muchas aplicaciones y utilidades del sistema operativo y que no interesa que se ejecuten en un contenedor aislado porque supondría tener que instalar todas estas herramientas en los contenedores y algunas de ellas necesitan tener acceso al sistema operativo huésped.

La ejecución de Docker complica la gestión ya que tenemos ahora además de tener que realizar la operación del software instalado hay que vigilar la ejecución de cada contenedor y las comunicaciones entre ellos que entre otras cosas significa que tenemos que tener otro interfaz de red en el sistema. 

En nuestro caso nuestro sistema se ejecuta en una placa base y en un procesador y no tenemos ningún interés en ejecutarlo en una cloud pública por lo cual perdemos la facilidad que nos aportan los contenedores de migrado al cloud.

No tiene sentido el autoescalado dinámico que es la gran ventaja de la contenerización ya que no vas a instalar un sistema como Kubernetes cuando tenemos unos pocos contenedores, la carga es muy baja y constante y el acceso a las aplicaciones como BTC-RPC-Explorer o RTL se realiza muy de vez en cuando y por una una única persona…

Resumiendo Docker es una gran tecnología que ya está aquí y va a continuar con nosotros durante un buen tiempo, si a eso le sumamos los orquestadores como Kubernetes y sobre estos Rancher, Openshift… tenemos el kit completo para conseguir un dimensionamiento a medida, pero en un caso como el nuestro donde lo que queremos es ejecutar un software en un hardware mínimo no necesitamos esas ventajas y nos evitamos añadir complejidad al sistema y tener un mayor consumo de recursos.

La versión del artículo en inglés Why don’t we use Docker in BCubium full node