El antiguo nodo con el que operaba en Madrid lo instalé en una Raspberry Pi, la misma que hoy utilizo para Pi-hole y Unbound. Esta vez, con un Mini PC bastante más potente, esperaba una instalación más sencilla y rápida y, aunque así ha sido, también me he encontrado con algunos problemas que comentaré más adelante.

Si entonces seguí la guía de RaspiBolt, esta vez he utilizado MiniBolt, su adaptación para Mini PC. No voy a repetir aquí los pasos de instalación, que ya están bien documentados, sino explicar qué he instalado, para qué sirve cada componente y algunas cosas que he ido aprendiendo durante el proceso. MiniBolt está pensada principalmente para Ubuntu y yo estoy utilizando Debian, pero las diferencias han sido ínfimas ya que Ubuntu deriva de Debian.

Bitcoin Core

El componente principal es Bitcoin Core, la implementación de Bitcoin más utilizada. Es el software que descarga y valida la blockchain, comprueba que los bloques y las transacciones cumplen las reglas del protocolo y se comunica con otros nodos de la red.

Es importante distinguir entre Bitcoin y Bitcoin Core. Bitcoin es el protocolo y la red; Bitcoin Core es solamente una implementación de ese protocolo. Existen otras alternativas, todas ellas usadas de forma marginal salvo Bitcoin Knots, en la que es interesante detenerse.

Knots ha ganado bastante popularidad a raíz de la discusión sobre Ordinals e inscriptions: desde finales de 2022 empezó a utilizarse el espacio de los bloques para incluir imágenes y otros datos. Ha habido debate en la comunidad al respecto: algunos consideran que si una transacción paga las comisiones correspondientes y cumple las reglas de Bitcoin, ese uso es perfectamente válido; otros, por contra, catalogan estas imagenes como spam y creen que el espacio de la blockchain debe utilizarse únicamente para transacciones monetarias. Bitcoin Knots aplica por defecto políticas más restrictivas a las transacciones que un nodo guarda en su mempool y retransmite a otros nodos. Pero esto no significa que pueda ignorar esas transacciones si finalmente aparecen dentro de un bloque válido. Hay una diferencia importante entre las políticas de mempool, que cada nodo puede configurar, y las reglas de consenso, que determinan qué bloques se aceptan como válidos.¹

Esta discusión ha desembocado recientemente en el BIP-110², una propuesta de soft fork temporal que buscaba trasladar algunas de estas restricciones desde la política local de cada nodo hasta las propias reglas de consenso. La idea era que los nodos que ejecutasen software que aplicase BIP-110 comenzasen, llegado cierto punto, a rechazar como inválidos los bloques que no señalizasen su apoyo a las nuevas reglas. Al alcanzarse el bloque 961632, minado hace menos de una semana, comenzó la fase de señalización obligatoria para esos nodos y se produjo una separación de la cadena. La inmensa mayoría del hashrate continuó minando sobre Bitcoin con las reglas anteriores, donde los bloques siguieron produciéndose aproximadamente cada diez minutos, mientras que la rama que aplicaba BIP-110 quedó con una fracción mínima del hashrate y apenas ha sido capaz de producir unos pocos bloques desde entonces.

El episodio recuerda en cierta medida al BIP-148 de 2017. Los nodos que ejecutasen software que aplicase las reglas de ese BIP rechazarían los bloques que no señalizasen la activación de SegWit, una modificación del protocolo que permitió aprovechar mejor el espacio disponible en cada bloque sin tener que aumentar su tamaño. En aquel caso la presión ejercida por el BIP-148 terminó contribuyendo a desbloquear la activación de SegWit, que hasta entonces no había conseguido el apoyo minero necesario.

Una de las cosas que esta discusión sobre el BIP-110 deja bastante clara es que ejecutar un nodo no equivale simplemente a tener un voto sobre la red, como explica Satoshi en el Whitepaper de 2009:

“If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote.”

Mi nodo puede decidir qué reglas acepta y, por tanto, qué considera Bitcoin, pero no puede obligar a los mineros, exchanges o demás usuarios a seguir esas mismas reglas. Para que una modificación impulsada por quienes operan nodos tenga efectos sobre el conjunto de la red hace falta que exista suficiente apoyo económico dispuesto a seguir esa cadena. Parte de quienes apoyaban el BIP-110 parece haber interpretado lo sucedido en 2017 como una demostración de que una minoría suficientemente «intolerante» de usuarios —los plebs, como ellos mismos se llaman— podía imponerse por sí sola a la mayoría económica. Una especie de sueño febril populista que se ha roto esta última semana.

Personalmente nunca he creído que ejecutar un nodo me otorgue algún tipo de poder sobre la red. Lo hago principalmente porque me interesa entender cómo funciona Bitcoin, aunque también tiene utilidades prácticas: puedo verificar la blockchain por mí mismo, consultar y retransmitir mis propias transacciones sin depender de nodos de terceros y conectar otros servicios a mi propia infraestructura. Nada de esto es imprescindible para un usuario de Bitcoin que simplemente quiera utilizar la red.

Problemas de ancho de banda

Relacionado con todo esto está el hecho de que la IBD (Initial Block Download) me provocó un problema que inicialmente no relacioné con Bitcoin Core.

Durante un par de días el Wi-Fi funcionaba bastante peor de lo habitual. Algunas páginas tardaban en cargar y la conexión parecía inestable. Pensé que podía ser la descarga de la blockchain, pero recordé que cuando la descargué un año antes desde una Raspberry Pi no había tenido estos problemas, así que empecé buscando la causa en la propia red inalámbrica.

Separé las redes de 2,4 y 5 GHz, que inicialmente compartían el mismo nombre, para poder elegir de forma explícita a cuál conectarme. La idea era utilizar preferentemente la de 5 GHz, que ofrece más ancho de banda y, en mi caso, estaba bastante menos congestionada por las redes vecinas. En 2,4 GHz revisé los canales utilizados alrededor, probé distintas configuraciones y realicé mediciones con iperf3; también fui ajustando el ancho de canal para reducir las interferencias.

Otra de las cosas que comprobé fue la MTU (Maximum Transmission Unit), es decir, el tamaño máximo de un paquete IP que puede atravesar un enlace sin tener que fragmentarse. Para ello utilicé ping indicando que los paquetes no pudiesen fragmentarse:

ping -M do -s *TAMAÑO_A_PROBAR* -c 20 1.1.1.1

La opción -M do obliga a enviar el paquete con la indicación de que no debe fragmentarse, mientras que -s establece el tamaño de los datos enviados. A este último valor hay que añadir 28 bytes correspondientes a las cabeceras IP e ICMP. Así, por ejemplo, si escribimos -s 1464 lo que realmente se está probando es un paquete IP de 1492 bytes. Las pruebas con tamaños de 1500, 1492 y 1480 bytes fallaban, mientras que 1428 bytes sí pasaban correctamente. Afinando después el límite comprobé que el tamaño máximo admitido a lo largo de todo el recorrido era de 1440 bytes. En mi router la opción que venía configurada por defecto era MTU: 1500, por lo que lo bajé a 1440.

Todas estas pruebas conllevaron leves mejoras y me sirvieron para refrescar algunos conceptos y aprender otros, pero la lentitud al navegar seguía ahí. Cuando probé a detener Bitcoin Core, la conexión volvió inmediatamente a la normalidad.

La diferencia con la Raspberry Pi que había utilizado para mi nodo anterior era el propio rendimiento del equipo. La Raspberry tardaba mucho más en procesar y verificar los bloques, así que no podía descargar datos de forma continua a gran velocidad. Eso hizo que la sincronización completa tardase semanas, pero también evitaba que ocupase todo el ancho de banda disponible. El Mini PC, en cambio, puede validar los bloques mucho más rápido y pedir continuamente los siguientes, por lo que durante la IBD estaba utilizando prácticamente todo el ancho de banda que tenía disponible. Además, yo mismo había favorecido una sincronización rápida aumentando la caché de Bitcoin Core y reduciendo el tráfico de transacciones mediante estas opciones en bitcoin.conf:

# Aumenta la memoria RAM, reduciendo accesos a disco .
dbcache=8192

# Evita el tráfico de transacciones no confirmadas: solo bloques.
blocksonly=1

En esos momentos en los que la lentitud navegando por Internet era exasperante, Bitcoin Core estaba descargando bloques del año 2023, coincidiendo con el auge de Ordinals e inscriptions con los bloques llenos de imágenes, videos y demás datos no monetarios. La sensación era parecida a circular por una carretera prácticamente vacía y encontrarse de repente con bastante más tráfico.

Para solucionar este problema decidí limitar el ancho de banda del Mini PC desde el router a 5.000 KB/s de descarga y 3.000 KB/s de subida. La sincronización tarda así un poco más, pero mientras tanto puedo utilizar Internet con normalidad.

Una solución mejor habría sido utilizar Smart Queue Management. En lugar de imponer simplemente un límite fijo, estos sistemas gestionan las colas de tráfico para evitar que una descarga intensiva monopolice la conexión y aumente la latencia del resto de dispositivos. Mi router no dispone de esta funcionalidad, así que el límite manual es suficiente por ahora. Este problema es temporal: una vez terminada la IBD, mantener el nodo actualizado requiere mucho menos ancho de banda.

Indexador y explorador

Fulcrum

Una vez finalizada la IBD —me llevó solo cuatro días; por comparar, con la Raspberry Pi había tardado unas cuatro semanas— pasé al siguiente paso de la guía: instalar un indexador.

Bitcoin Core permite validar la blockchain y consultar transacciones concretas, pero llevamos ya 17 años de transacciones y es muchísima información almacenada, por lo que cuando le preguntamos a Bitcoin Core «¿qué transacciones están relacionadas con esta dirección?» o «¿cuál es el historial completo de esta cartera?» puede tardar en responder. Un indexador recorre toda la blockchain y construye una base de datos adicional organizada para poder hacer este tipo de consultas de forma rápida. Es la pieza que permite, por ejemplo, conectar una cartera Electrum o un explorador de bloques a mi propio nodo en vez de depender de servidores externos.

En mi anterior nodo había utilizado Electrs, una implementación del protocolo Electrum escrita en Rust y optimizada para equipos con recursos modestos. Su propia documentación destaca que mantiene un índice bastante reducido —aproximadamente un 10 % adicional sobre el tamaño de la blockchain— y un consumo bajo de CPU y memoria una vez terminada la indexación.

La guía que ofrece MiniBolt no es la de electrs sino la de Fulcrum, otro servidor compatible con el protocolo Electrum pero con un planteamiento diferente. Fulcrum construye un índice bastante más completo, lo que le permite responder más rápido a consultas grandes, a cambio de consumir más espacio en disco. En principio pensé en repetir con electrs por lo explicado en este podcast de Lunaticoin. Fulcrum tenía una desventaja importante frente a electrs, y es que, pese a ser mucho más rápido, una interrupción inesperada mientras escribía en la base de datos podía corromperla y obligar a reconstruir todo el índice. Sin embargo, este problema parece haber quedado resuelto con Fulcrum 2.0, publicado con un nuevo formato de base de datos.

Teniendo eso en cuenta, y dado que en el Mini PC tengo recursos de sobra para asumir su mayor consumo de disco y memoria, finalmente opté por Fulcrum; para mi sorpresa la indexación inicial ha resultado incluso más lenta que la propia descarga de la blockchain, llevándome seis días. Una vez terminada la indexación, el siguiente paso fue conectar la cartera directamente a Fulcrum; si de carteras hablamos, recomiendo Sparrow Wallet. Sparrow ofrece tres formas principales de consultar la red Bitcoin: conectarse a un servidor público Electrum, conectarse directamente a Bitcoin Core o utilizar un servidor Electrum privado, como Fulcrum o electrs. La primera opción es la más sencilla, pero obliga a confiar en un tercero. Las otras dos permiten utilizar nuestra propia infraestructura. Un servidor Electrum privado tiene además dos ventajas frente a conectarse directamente a Bitcoin Core: las consultas son más rápidas y ofrece algo más de privacidad, ya que a diferencia de la wallet de Bitcoin Core no mantiene almacenada información específica sobre las claves y el saldo de nuestra cartera.

De esta forma, Bitcoin Core valida la blockchain, Fulcrum la indexa para que pueda consultarse de forma eficiente y Sparrow utiliza ese índice para obtener la información de mis carteras sin depender de infraestructura ajena.

BTC RPC

El último componente que he instalado es BTC RPC Explorer, un explorador de bloques que se conecta directamente a Bitcoin Core. Un explorador permite consultar de forma visual información de la blockchain: bloques, transacciones, direcciones, comisiones o datos generales de la red, sin tener que hacerlo mediante comandos. En mi caso, BTC RPC Explorer obtiene toda esa información de mi propio nodo, por lo que no depende de servicios externos. Lo he configurado como se indica en la guía y ya puedo acceder a él desde cualquier dispositivo conectado a mi red local.

La idea es exponer también el explorador a Internet para poder acceder a él desde fuera de casa y dejarlo disponible como parte del homelab. Esto se puede hacer con Tor, pero también quiero que se pueda acceder desde clearnet. Para hacerlo utilizaré Cloudflare Tunnel, que permite publicar un servicio local sin abrir directamente puertos del router.

Más detalle sobre esto en la siguiente entrada.