Cómo ejecutar un nodo completo de Bitcoin en un VPS

Un nodo completo es la única forma de usar Bitcoin sin preguntarle a otro cuál es la verdad. Cualquier otra opción —un explorador de bloques, un monedero ligero que habla con un servidor público, un saldo en un exchange— significa confiar tu historial a un tercero y entregarle tu privacidad por el camino. Bitcoin Core en sí tarda unos diez minutos en instalarse. Lo que realmente decide si tu nodo es útil es la máquina que hay debajo: cuánto disco le diste, si la subida está medida y qué puede ver el host.

Qué hace un nodo completo — y qué no hace

Un nodo completo descarga todos los bloques, comprueba por sí mismo todas las firmas y todas las reglas de consenso, y mantiene su propia copia del conjunto actual de monedas gastables. Es un verificador. No es un minero, y por sí solo tampoco es un monedero.

• Valida de forma independiente — ni un explorador, ni un exchange ni un servidor de monedero ligero deciden qué es válido o cuál es tu saldo.
• Evita que filtres tus direcciones al servidor de un desconocido cada vez que un monedero sincroniza, que es la mayor fuga de privacidad que tiene la mayoría de los usuarios de Bitcoin.
• Retransmite bloques y transacciones a otros, que es la parte que ayuda a la red y no solo a ti.
• No gana nada, no vota nada, y no hace que tus monedas estén más seguras si tus claves ya se gestionan mal.

De archivo, podado o indexado: tres huellas de disco muy distintas

Esta única decisión determina el plan que necesitas, así que tómala antes de contratar nada. Los tres modos verifican la cadena exactamente de la misma manera — la diferencia está solo en cuánto se queda en disco una vez terminada la verificación.

• Podado (pruned) — Core descarga y comprueba todo, y luego descarta los archivos de bloques antiguos y conserva solo los recientes. Con prune=5000 los datos de bloques se quedan en torno a 5 GB; suma el conjunto UTXO y el sistema operativo y te sitúas cerca de 25 GB en total.
• De archivo (archival) — se conserva cada bloque para siempre. Hoy eso supera los 750 GB de datos de bloques, creciendo aproximadamente 7 GB al mes, más el conjunto UTXO encima. Lo necesitas para servir bloques históricos a otros peers, o para reindexar más adelante sin volver a descargar la cadena.
• Indexado (indexed) — archivo completo más txindex=1, que te permite buscar cualquier transacción por ID y es lo que esperan los exploradores de bloques y parte del software de servidor. Añade decenas de gigabytes extra, y no se puede combinar con el podado.

Elegir un VPS para un nodo de Bitcoin: disco, RAM y un puerto no medido

Bitcoin Core es paciente con la CPU y exigente con el disco. Las lecturas y escrituras aleatorias contra la base de datos UTXO son lo que hace que una sincronización sea rápida o miserable, por lo que aquí el NVMe importa mucho más que el número de núcleos. Todos los planes de la gama VPS offshore incluyen NVMe Gen4 en RAID-10 y ancho de banda no medido, así que la elección real es la capacidad.

• Nodo podado: VPS-4 a $7.49/mo — 2 vCPU EPYC, 4 GB DDR5 ECC y 60 GB de NVMe, con margen cómodo para prune=5000 más los logs. El VPS-2 a $3.99 también funciona si podas de forma más agresiva.
• Nodo podado que sincroniza rápido: VPS-8 a $13.99/mo — 4 vCPU y 8 GB te permiten asignarle a Core varios gigabytes de dbcache, que es la palanca individual más grande sobre el tiempo de sincronización.
• Nodo de archivo: VPS-64 a $89.99/mo es el único nivel de VPS cuyos 800 GB de NVMe alcanzan por poco para una cadena sin podar — y, al tamaño actual, eso deja apenas un año de margen.

Para un nodo de archivo o indexado, haz la cuenta con honestidad en lugar de comprar el VPS más grande por reflejo: un servidor dedicado parte de $64/mo con 64 GB de memoria y 2 × 1 TB de NVMe, así que resulta a la vez más barato y con mucho más margen que el nivel de VPS más grande. Si piensas conservar la cadena durante años, o apilar junto a él un servidor Electrum y un sitio alojado sin KYC, empieza ahí en lugar de actualizar dos veces.

Paso a paso: de una recarga en cripto a un nodo sincronizado

1. 01Crea una cuenta con un correo desechableUn correo y una contraseña. Sin nombre, teléfono ni identificación, de modo que nada por nuestra parte vincula el nodo contigo.
2. 02Recarga tu saldo en criptoFinancia un saldo prepago con Bitcoin, Monero o cualquiera de las 8 criptomonedas disponibles. Nunca caduca ni se congela.
3. 03Despliega el VPSElige un plan, una región y una imagen de Debian o Ubuntu. El acceso root está listo en torno a un minuto de media.
4. 04Instala Bitcoin Core y verifica la descargaDescarga la versión desde el proyecto Bitcoin Core y comprueba las firmas antes de descomprimirla. Saltarse ese paso es lo que lleva a acabar ejecutando el binario de otra persona.
5. 05Ejecútalo con su propio usuario bajo systemdUn usuario bitcoin dedicado, un directorio de datos de su propiedad, y un archivo unit para que el nodo vuelva por sí solo tras un reinicio.
6. 06Escribe bitcoin.conf, inícialo y observa el logDefine tu nivel de prune, el dbcache y las opciones de red, inicia el servicio, y sigue el log hasta que el progreso de verificación llegue a 1.

Las líneas de bitcoin.conf que realmente importan

Core viene con valores por defecto sensatos, y una buena configuración suele tener seis o siete líneas. Estas son las que merece la pena entender en lugar de copiar de un post de un foro.

• dbcache — memoria para la base de datos UTXO, 450 MB por defecto. Subirlo a varios miles para la sincronización inicial es la mejora de velocidad más barata disponible, y luego puedes volver a bajarlo.
• prune — un tope de tamaño en MB para el almacenamiento de bloques, mínimo 550. Pasar de podado a archivo completo más adelante implica descargar la cadena otra vez, así que decide antes del primer arranque.
• txindex=1 — construye un índice completo de transacciones. Actívalo solo si alguna herramienta que realmente usas lo necesita; añadirlo más tarde obliga a un reindexado.
• listen=1 con el puerto 8333 abierto — te convierte en un nodo a la escucha al que otros peers pueden alcanzar. Esa es la diferencia entre usar la red y contribuir a ella.
• maxuploadtarget — un límite diario flexible sobre el tráfico saliente, que vale la pena configurar en cualquier host que mida la transferencia.
• blocksonly=1 — deja de retransmitir transacciones sueltas. Recorta el ancho de banda de forma drástica, a costa de un mempool útil y de ayudar a la propagación.

Descarga inicial de bloques: qué es lo que realmente la hace lenta

La primera sincronización es la única parte genuinamente pesada del trabajo. Core reproduce toda la cadena, y aunque por defecto se salta la comprobación de scripts por debajo de un bloque reciente predefinido, sigue reconstruyendo desde cero todo el conjunto UTXO — así que el trabajo está dominado por la E/S de disco aleatoria y el hashing, no por tu conexión. En NVMe Gen4 con un dbcache generoso, una sincronización completa normalmente termina en bastante menos de un día; el mismo trabajo en un disco mecánico puede tardar una semana. Dale más memoria en lugar de más núcleos, y resiste la tentación de reiniciarlo por impaciencia: el progreso se escribe periódicamente, pero un reinicio a mitad de un flush te cuesta la cache por la que estabas pagando.

Ejecutar el nodo sobre Tor

Un nodo a la escucha se anuncia a otros peers. En una dirección de la red clara ese anuncio es público, y apunta a tu servidor. Core tiene soporte Tor de primera clase: dale un proxy SOCKS de Tor local y acceso al puerto de control de Tor, y publicará su propio servicio onion y aceptará ahí conexiones entrantes. Añade onlynet=onion y no hablará con la red clara en absoluto.

Esto es un trabajo distinto a ejecutar un repetidor Tor, que transporta el tráfico de otras personas y es deliberadamente público. Aquí Tor es simplemente cómo tu propio nodo llega a sus peers, y la contrapartida es modesta: los nodos solo-onion sincronizan algo más despacio y disponen de un grupo de peers más pequeño, lo cual rara vez es un problema para una máquina que dejas funcionando de forma continua.

Ancho de banda: el coste que nadie presupuesta

Un nodo a la escucha sube mucho más de lo que descarga. Cada peer que hace su propia sincronización inicial puede tirar de ti cientos de gigabytes, y un nodo de archivo bien conectado sirve tranquilamente varios terabytes al mes si se lo permites. En un host medido eso es una factura por exceso — es exactamente el perfil de tráfico que los planes de hosting «ilimitados» están redactados para excluir. La transferencia no medida es estándar en toda la gama aquí, y si quieres sembrar la cadena de forma agresiva para otros, la línea 10 Gbps Unmetered desde $34.99/mo incluye un puerto dedicado para ello. Si prefieres mantenerte modesto, limítalo deliberadamente con maxuploadtarget en lugar de dejarlo al azar.

Conectar monederos, un servidor Electrum o BTCPay

Un nodo por sí solo es solo la mitad de la instalación — el objetivo es hacer que tu propio software hable con él en lugar de con el de un desconocido. Monederos como Sparrow y Specter se conectan directamente al RPC de Core a través de un túnel. Los monederos con protocolo Electrum necesitan un servidor intermedio: electrs o Fulcrum construyen su propio índice a partir de los archivos de bloques en bruto, que es una de las razones concretas para mantenerte sin podar. Y si quieres aceptar pagos tú mismo, BTCPay Server ejecutándose contra tu nodo elimina por completo al procesador de pagos — la misma lógica de autoalojamiento que poner en marcha un sitio web sin KYC.

Una regla se cumple sin importar el stack: el nodo verifica, y tus claves viven en otro sitio. Usa un monedero hardware o un firmante offline, y deja que la máquina alquilada no haga nada más que validar. Una máquina que no posees físicamente no es el lugar donde deben reposar fondos importantes.

La contrapartida honesta de privacidad de un nodo que no posees

Un nodo en un VPS no es idéntico a uno bajo tu escritorio, y merece la pena ser preciso sobre por qué. Elimina la fuga más grande y más común: consultar exploradores públicos y servidores Electrum de terceros que registran exactamente qué direcciones preguntaste. Lo que no puede eliminar es al host. Cualquiera con acceso físico a una máquina puede en principio leer su disco y su memoria, y el cifrado de disco completo en un servidor remoto te protege frente a una unidad robada, no frente a una que está en marcha.

Así que la pregunta útil no es «¿puede verlo el host?» sino «¿sabe el host quién soy?». El hosting sin KYC responde a esa: un correo y una contraseña, sin verificación, nada registrado que filtrar ni que entregar ante una citación judicial. Pagar desde un saldo en cripto elimina al banco. Hasta dónde llevas el lado del pago es una cuestión de modelo de amenaza — Bitcoin es pseudónimo, no anónimo, así que las monedas rastreadas hasta un exchange verificado igualmente llevan a alguna parte, mientras que recargar en Monero cierra esa brecha a nivel de protocolo. El mismo razonamiento se aplica a ejecutar un nodo de Monero, donde lo que proteges es el vínculo entre el monedero y el nodo.

Errores que dejan un nodo atascado, inactivo o expuesto

• El disco llenándose a mitad de la sincronización porque el podado se decidió después de los hechos — configúralo antes del primer arranque, no a medio camino.
• El puerto 8333 dejado cerrado en el firewall, de modo que el nodo solo hace conexiones salientes y nunca sirve a un solo peer.
• RPC enlazado a 0.0.0.0 «solo para pruebas», que en una IP pública se descubre en cuestión de horas.
• txindex activado por reflejo en un disco pequeño, para descubrir después que quitarlo exige un reindexado completo.
• El nodo ejecutado como root desde un directorio home sin unit de systemd, de modo que un solo reinicio termina el experimento en silencio.

Ninguno de estos son fallos exóticos. Son lo que ocurre cuando la máquina se elige solo por precio y los detalles se dejan para después. Elige el disco para el modo que realmente quieres, mantén abierto el puerto de peers y cerrado el RPC, y un nodo de Bitcoin es una de las cosas menos exigentes que puedes dejar funcionando durante años.