Cómo correr un nodo propio de Bitcoin

Con qué se termina

Una máquina corriendo Bitcoin Core que descargó la cadena por su cuenta, revisó cada bloque contra las reglas y puede responder "¿llegó ese pago?" desde su propia copia en lugar de preguntárselo a una empresa, con una wallet apuntada a ella.

Esta guía asume que ya se sabe qué es un nodo y para qué sirve. Si no, conviene leer eso primero: este texto es la parte de hacerlo.

Revisado en agosto de 2026 contra Bitcoin Core 31.1, publicado el 8 de julio de 2026, y contra la documentación del propio Core. Tanto las versiones como el tamaño de la cadena se mueven, así que cada cifra de abajo conviene contrastarla con la página de descarga en lugar de confiar en un artículo de blog, incluido este.

Antes de empezar

Disco. La página de descarga de Core pide "una descarga única de unos 600 GB de datos más otros 5 a 10 GB por mes", y dice que la poda lo baja hasta unos 10 GB. Esos 600 GB son donde estaba la cifra en agosto de 2026, y sólo crece.

Memoria RAM. Core no publica un mínimo, así que este es el número que se comporta como tal: dbcache vale 1024 MiB por defecto, o 450 MiB cuando la máquina tiene menos de 4096 MiB de RAM, según las notas sobre memoria de Core. Con 4 GB se está cómodo. Con 2 GB también funciona, más lento, porque Core achica su caché de validación para entrar.

Ancho de banda. Los 600 GB son la descarga, una vez. Los 5 a 10 GB mensuales son sobre todo subida, porque un nodo que acepta conexiones entrantes les sirve bloques a otros.

Tiempo. Nadie publica una cifra honesta para la descarga inicial y este texto tampoco lo hará: de horas a días, y lo decide más la velocidad del disco que la red.

GPG, para el paso tres: brew install gnupg en macOS, apt install gnupg en Debian.

El costo que se acepta

Este es el raro procedimiento de Bitcoin donde lo que se pierde no son monedas. Un nodo, por defecto, no guarda dinero: equivocarse cuesta un fin de semana.

Lo que se asume a cambio es un compromiso operativo. Un nodo es un servicio que ahora se opera: tiene que quedar en línea para valer algo, hay que actualizarlo cuando Core publica una corrección de seguridad, y una vez que la wallet apunta ahí, la wallet deja de funcionar cada vez que el nodo se cae. La gente abandona nodos por esto último más que por cualquier otra cosa.

Pasos

Conseguir el software, y probar que es el software

Este es el paso que casi todas las guías comprimen en "descargar Bitcoin Core", y el que más importa. Core se compila de forma reproducible: personas independientes compilan el mismo código fuente, obtienen binarios idénticos byte a byte y firman la lista de hashes resultante. Saltearse la comprobación tira eso a la basura y deja como única garantía una conexión web.

1. Descargar el binario del sistema correspondiente desde bitcoincore.org/en/download, junto con SHA256SUMS y SHA256SUMS.asc de la misma página.
2. Comparar el binario contra la lista: sha256sum --ignore-missing --check SHA256SUMS en Linux o macOS, certUtil -hashfile <archivo> SHA256 en Windows. El éxito es el nombre del archivo seguido de OK.
3. Importar varias claves de quienes compilan, desde el directorio builder-keys de bitcoin-core/guix.sigs, con un gpg --import <nombre>.gpg por cada una.
4. Revisar las firmas de la lista misma: gpg --verify SHA256SUMS.asc. Lo que se busca son varias líneas que digan gpg: Good signature, de claves elegidas a conciencia.

El paso 2 por sí solo no prueba nada que valga la pena: prueba que el archivo coincide con una lista que llegó del mismo lugar que el archivo. El paso 4 es lo que le da sentido a la lista.

Core también trae un script que hace los cuatro, ./contrib/verify-binaries/verify.py pub 31.1, documentado en contrib/verify-binaries.

Configurarlo antes del primer arranque

5. Instalar o descomprimir el binario.
6. Crear bitcoin.conf en el directorio de datos antes de arrancar, porque algunas de estas opciones son molestas de cambiar después. Va en ~/.bitcoin/bitcoin.conf en Linux, ~/Library/Application Support/Bitcoin/bitcoin.conf en macOS y %APPDATA%\Bitcoin\bitcoin.conf en Windows (doc/bitcoin-conf.md):

# Responder JSON-RPC, para que el software de wallet local llegue al nodo.
server=1

# Caché de validación en MiB. Subirla para la descarga inicial, bajarla después.
dbcache=4096

# Aceptar conexiones entrantes. Esto es lo que vuelve al nodo útil para otros.
listen=1

# Objetivo de tráfico de salida, MiB cada 24 horas. 0 significa sin límite.
maxuploadtarget=5000

# Filtros compactos de bloque, para que una wallet escanee su historia rápido.
blockfilterindex=1

Ese dbcache es generosidad temporal, conviene bajarlo cuando termina la descarga, y maxuploadtarget exceptúa los bloques minados en la última semana, según el texto de ayuda de Core, así que limita servir historia y no todo el tráfico.

7. Arrancarlo: bitcoind -daemon, o abrir Bitcoin-Qt para la versión gráfica. Sólo uno de los dos puede correr a la vez.
8. Dejarlo tranquilo. Esta es la descarga inicial de bloques, e interrumpirla es seguro pero desperdicia trabajo.

Comprobar que funcionó

Correr bitcoin-cli getblockchaininfo. Cuatro de sus campos responden la pregunta, y la referencia de RPC los define todos:

• initialblockdownload es la respuesta directa. Mientras diga true, el nodo sigue poniéndose al día y no hay que creerle que un pago llegó.
• verificationprogress es una estimación entre 0 y 1, y no es lineal: el último uno por ciento tarda muchísimo más que el primero, porque los bloques recientes vienen llenos.
• blocks y headers deberían ser iguales. Que las cabeceras vayan adelante es normal a mitad de sincronización: Core baja primero la cadena de cabeceras y después rellena los bloques.
• size_on_disk es lo que está costando en disco, y chain debería decir main.

Sincronizado y validando son lo mismo acá, con un matiz. La opción assumevalid de Core viene con el hash de un bloque incorporado y, para ese bloque y sus antecesores, va a "asumir que él y sus antecesores son válidos y potencialmente saltear la verificación de sus scripts". Todo lo demás se revisa igual desde cero: el calendario de emisión, la prueba de trabajo, si una entrada existe y no fue gastada ya. Poner assumevalid=0 elimina cualquier atajo, a cambio de una descarga bastante más larga.

La poda, y qué cuesta exactamente

Con prune=550 o más, un objetivo en MiB, Core borra los datos de bloques viejos cuando termina con ellos y conserva el conjunto de salidas no gastadas y una ventana reciente. Un nodo podado validó cada bloque que vio, así que es un nodo completo en el sentido que importa.

Cuatro cosas que se resignan, y la tercera es la que sorprende:

1. Se deja de servir historia. Nadie puede sincronizar desde ese nodo. Es una pérdida para la red más que para uno, pero es real.
2. txindex queda fuera. No se pueden buscar transacciones arbitrarias por su ID.
3. Los reescaneos de wallet no pueden pasar de pruneheight. Al importar una wallet cuyas transacciones son anteriores a la ventana podada, el nodo no las encuentra. Una fecha de nacimiento correcta en la wallet más blockfilterindex=1 cubre casi todos los casos; una historia genuinamente vieja pide un nodo sin poda.
4. Revertir la decisión exige volver a descargar la cadena entera, según el texto de ayuda de Core. La poda es casi un camino de ida.

Conectar una wallet

Un nodo al que nadie apunta es un pasatiempo. En Sparrow, poner el tipo de servidor en Bitcoin Core y la URL en 127.0.0.1 con el puerto por defecto, y dejar la autenticación en el archivo de cookie, que Core escribe en el directorio de datos y Sparrow encuentra solo. Las notas de conexión de Sparrow agregan dos requisitos del lado de Core: server=1 activado, y disablewallet=1 sin activar.

Después conviene confirmar que la wallet realmente lo está usando y no cayendo en silencio a un servidor público. Detener bitcoind y mirar cómo la wallet pierde la conexión. Si sigue tan campante, nunca estuvo hablando con ese nodo.

Si algo sale mal

gpg: Can't check signature: No public key. No se verificó nada. Importar las claves de quienes compilan y correrlo de nuevo.

gpg: WARNING: This key is not certified with a trusted signature. Es esperable, no una falla: significa que no se firmó personalmente la clave de esa persona, cosa que casi nadie hace. Lo que importa es el Good signature de la línea de arriba.

BAD signature. Detenerse ahí. No ejecutar el binario, y no tratarlo como una descarga fallida.

La sincronización se arrastra con la luz del disco fija. Casi siempre es el disco y no la red, y casi siempre un disco mecánico o una tarjeta SD. Subir dbcache si hay RAM, y mover el directorio de datos a un SSD.

El disco se llena a mitad de la descarga. Agregar prune=550 y reiniciar. Core poda lo que ya tiene.

Cannot obtain a lock on data directory. Ya hay otra instancia de Core corriendo, casi siempre Bitcoin-Qt olvidado detrás de una ventana.

Lo que correr un nodo no hace

No genera ingresos. No hay recompensa, ni rendimiento, ni nada que stakear. Quien venda hardware de nodo con un argumento de retorno de inversión está vendiendo otra cosa.

No es minería. Los mineros proponen bloques haciendo prueba de trabajo y cobran por eso. Un nodo revisa lo que ellos proponen y no cobra nada.

No vuelve privadas las transacciones propias. Arregla una sola filtración: una wallet liviana le cuenta a alguna empresa por qué direcciones pregunta, y un nodo propio no le cuenta a nadie. Del resto no se ocupa. La cadena sigue siendo pública, las salidas no gastadas siguen enlazadas entre sí, y todo lo que se transmite queda a la vista de cada nodo que lo retransmite. La privacidad es una disciplina aparte; el nodo es un componente de ella.

No da un voto. Un nodo hace cumplir las reglas para sí mismo. No le gana la votación a nadie, y si sus reglas difieren de las de todos los demás, el resultado es quedarse solo en otra cadena.

Lo que sí da es más estrecho y mejor. Cuando la wallet dice que un pago se confirmó, eso ahora es una afirmación que revisó una máquina propia, contra reglas elegidas por uno.