Seis pasos desde un VPS nórdico desnudo hasta su propio monerod — binarios verificados, una configuración reforzada, completo o podado, accesible por SSH, WireGuard o un onion v3. Un nodo remoto no puede leer su saldo, pero sí puede ver a su IP difundir su transacción — esta guía cierra esa única brecha. Probado en Debian 12 con la línea v0.18.
Aprovisionar
Disco primero, luego refuerzo
Verificar
Firma, luego instalación
Configurar
monerod.conf + systemd
Sincronizar
Un día o dos, bajo vigilancia
Conectar
SSH, WireGuard u onion
Anonimizar
Difundir por Tor
Casi todos los monederos de Monero se distribuyen apuntando al demonio de otra persona, porque la alternativa es un cuarto de terabyte y dos días de espera. Ese valor por defecto es defendible, y la consiguiente pérdida de privacidad se describe habitualmente mal en ambas direcciones: por quienes creen que un nodo remoto lee su saldo, y por quienes creen que no aprende absolutamente nada. Entender bien la forma de esa fuga es lo que le dirá si esta guía merece una tarde de su tiempo.
Lo que no puede hacer. No puede ver su saldo, sus direcciones ni sus claves. Un monedero de Monero no le dice a un nodo qué buscar; descarga bloques enteros a lo largo de un rango de bloques e intenta descifrar cada salida localmente con la clave de vista privada, que nunca sale del dispositivo. El nodo entrega los mismos bytes que entregaría a cualquiera. No puede saber cuáles de esas salidas, si es que alguna, eran suyas, y esa es una diferencia arquitectónica genuina respecto al modelo de monedero ligero usado en otros lugares, donde a un servidor se le entregan las direcciones que debe vigilar y por tanto sabe exactamente qué está vigilando.
Lo que sí puede hacer. Ve la dirección IP que se conectó. Ve el rango de bloques que esa IP solicitó, lo que acota cuándo se creó el monedero que hay detrás. Ve el ritmo de sus actualizaciones, que es un patrón de uso. Y cuando usted gasta, recibe la transacción firmada primero, antes de que el resto de la red la tenga, así que está en condiciones de registrar que esta transacción entró en la red desde esta dirección, en este segundo. Todo lo demás en Monero está diseñado para romper exactamente ese tipo de vínculo. Entregárselo a un desconocido, gratis, junto con una IP estable, es la parte que merece la pena corregir.
Y lo que sí puede hacer y nadie menciona. Puede mentir. Un nodo hostil, o simplemente averiado, puede servir una punta de cadena obsoleta para que su monedero informe de un pago entrante que no ha ocurrido, o no logre retransmitir una transacción que usted cree haber enviado. Nada de eso roba fondos —el monedero verifica lo que descifra—, pero sí le hace actuar sobre una visión falsa del mundo, lo cual, para un comerciante que espera una confirmación, es una pérdida en sí misma. Un nodo que usted mismo ejecuta es un nodo cuyas respuestas no tiene que sopesar.
| Qué queda expuesto | Nodo remoto público | Su nodo, red normal | Su nodo, por Tor |
|---|---|---|---|
| Su saldo y sus direcciones | Nunca | Nunca | Nunca |
| Su IP, al operador del nodo | Sí — un desconocido | Sí — usted | No |
| Ventana de creación del monedero | Sí — un desconocido | Sí — usted | Sí — usted |
| IP ↔ su transacción saliente | Sí — un desconocido | La IP de su servidor, a sus pares | Interrumpido por el tx proxy |
| Puede servirle una punta de cadena falsa | Sí | No | No |
"Ventana de creación del monedero" sigue siendo visible para usted en su propio nodo porque la solicitud se sigue produciendo: sencillamente deja de ser visible para cualquier otra persona. Ese es todo el sentido del ejercicio: no hacer desaparecer los metadatos, sino conseguir que usted sea la única parte que los posee.
Un nodo de Monero podado conserva un octavo de los datos de firma en anillo de los bloques antiguos y descarta el resto. Aun así, descarga y verifica cada bloque por sí mismo: podar no es confiar, es olvidar después de comprobar; y conserva íntegro todo lo que un monedero pide y todo lo que necesita otro par podado. El ahorro es de unos dos tercios del disco. Para un nodo cuyo trabajo es respaldar sus propios monederos, no hay ninguna diferencia funcional que llegue a notar.
El argumento a favor de un nodo completo es estrecho y real: solo un nodo completo puede entregar a un nodo totalmente nuevo todos los datos históricos que necesita para verificar la cadena desde cero, así que una red formada enteramente por nodos podados no funcionaría. Si tiene el disco, ejecutar uno completo es una contribución. Si no lo tiene, ejecutar uno podado no es una forma inferior de participar: es la configuración que debería elegir la mayoría de quienes se autoalojan.
Decídalo antes de arrancar el demonio. Pasar --prune-blockchain en la primera ejecución poda a la vez que sincroniza, lo cual es rápido y gratuito. Convertir después una base de datos completa implica detener el demonio y ejecutar sobre ella la herramienta independiente monero-blockchain-prune, que necesita horas y espacio libre para trabajar. Acertar con esto desde el principio cuesta una línea en un archivo de configuración; hacerlo mal cuesta una noche entera.
| Forma | Disco, mediados de 2026 | Plan que encaja | Elíjalo cuando |
|---|---|---|---|
| Podado · ajustado | ~90 GB | Sentinel · 2 vCPU / 4 GB / 120 GB · $3.90 | Quiere el nodo funcional más barato y acepta tener que revisar el disco más adelante |
| Podado · cómodo | ~90 GB | Garrison · 4 vCPU / 8 GB / 240 GB · $7.90 | La recomendación por defecto — años de margen, caché de base de datos caliente |
| Completo | 240 GB+ | Ravelin · 8 vCPU / 16 GB / 480 GB · $16.90 | Quiere una copia de archivo, o servir a nodos nuevos su sincronización inicial |
| Completo + servicio público | 240 GB+ | Bulwark · 16 vCPU / 32 GB / 960 GB · $32.90 | Tiene intención de transportar tráfico real de pares — aquí importa el ancho de banda no medido |
Los tamaños de la cadena son una estimación para mediados de 2026 y solo se mueven en una dirección. Verifique la cifra actual antes de decidirse por un plan: todo plan de NordBastion incluye ancho de banda no medido, que es justo lo que consume un nodo con plazas abiertas para pares.
Algo que no aparece en esta tabla: la RAM. El demonio en sí es modesto, y con 4 GB se ejecuta un nodo perfectamente. Lo que compra la memoria adicional es caché de páginas por delante de la base de datos, algo que se nota durante la sincronización inicial y durante el primer reescaneo completo de un monedero, más que en el funcionamiento del día a día. Si tiene que elegir entre más RAM o más NVMe con el mismo presupuesto, elija el NVMe, y eche un vistazo a la lista de planes antes de decidir.
En el panel: Order → VPS → Garrison para un nodo podado, Ravelin si quiere la cadena completa, imagen Debian 12. No se requiere ninguna dirección de correo electrónico para abrir la cuenta, no se pide documento de identidad en ningún momento, y la factura se liquida en Monero, una simetría agradable y también el camino más corto de un monedero a un servidor arrancado que conocemos. Elija el bastión por la latencia hacia usted, no hacia la red: las conexiones entre pares son asíncronas y no les importa, pero las actualizaciones de su monedero sí lo notarán.
Después, dedique la primera hora al muro. Un nodo de Monero es un servicio público por naturaleza —escucha en un puerto P2P y habla con desconocidos—, así que la base no es opcional: SSH solo con clave en un puerto no predeterminado, un cortafuegos que deniega por defecto, actualizaciones de seguridad desatendidas, fail2ban. La lista de refuerzo de la primera hora es la pieza complementaria, y merece la pena seguirla de principio a fin antes de que exista el demonio.
La configuración del cortafuegos para este nodo es inusualmente simple. Exactamente dos cosas deben ser accesibles desde fuera: su puerto SSH y el puerto P2P de Monero. Nada más: en particular, no el puerto RPC, al que el paso 05 accede a través de un túnel en su lugar.
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp # or your relocated SSH port
ufw allow 18080/tcp # Monero P2P — the only service port
ufw enable
ufw status numbered
Confirme el disco que realmente ha recibido antes de sincronizar sobre él un cuarto de terabyte, porque descubrir el déficit cuarenta horas después de iniciar la sincronización es un tipo de disgusto muy particular:
df -h /
# → the "Avail" column is your real budget, not the tier name
Está a punto de instalar un programa que mantendrá la visión de la red en la que confían sus monederos. Un monerod manipulado es la posición ideal desde la que mentirle a un monedero, así que el paso de verificación aquí no es un ritual: es la razón por la que el proyecto Monero publica siquiera un archivo de hashes firmado. Hágalo, una vez, correctamente.
Descargue el archivo de la CLI para Linux x86-64 y el archivo de hashes firmado desde la página oficial de descargas, junto con la clave pública del mantenedor tal como se publica allí. No tome la clave de una réplica de un servidor de claves de terceros que haya encontrado en un foro: tómela del proyecto, por TLS, de la misma página que la menciona.
apt update && apt install -y gnupg curl bzip2
cd /tmp
curl -LO https://downloads.getmonero.org/cli/linux64 # the release archive
curl -LO https://www.getmonero.org/downloads/hashes.txt # the signed hash list
# Import the signing key named on getmonero.org, then:
gpg --verify hashes.txt
# → "Good signature from ..." — anything else, stop here.
La suma de comprobación solo tiene sentido una vez que la firma se verifica. Calcule el hash del archivo que descargó y localice esa cadena exacta dentro del archivo que acaba de verificar:
sha256sum linux64
grep -F "$(sha256sum linux64 | cut -d' ' -f1)" hashes.txt
# → one matching line. No output means no match: do not install it.
Después, descomprima y coloque los dos binarios que necesita. El archivo contiene un directorio con número de versión; monerod es el demonio, y monero-blockchain-prune es la herramienta sin conexión que agradecerá tener si alguna vez cambia de opinión sobre la poda.
tar -xjf linux64
cd monero-x86_64-linux-gnu-*/
install -m 0755 monerod monero-blockchain-prune /usr/local/bin/
monerod --version
Anote en algún sitio donde vuelva a encontrarla la cadena de versión que imprime ese comando. Cuando se anuncie una actualización de red, querrá saber exactamente desde qué versión está actualizando, y “la última” no es una respuesta.
Dele al demonio su propio usuario sin privilegios y su propio directorio. Nada en un nodo de Monero necesita root una vez que está en marcha, y un servicio que habla con la internet abierta todo el día es precisamente el servicio que no quiere tener ejecutándose como root.
useradd --system --home /var/lib/monero --shell /usr/sbin/nologin monero
mkdir -p /var/lib/monero /var/log/monero
chown -R monero:monero /var/lib/monero /var/log/monero
/etc/monerod.conf — las mismas opciones que monerod acepta en la línea de comandos, escritas sin los guiones iniciales. Elimine la línea prune-blockchain si se decidió por un nodo completo; esa es la única línea que es irreversible.
# ── storage ────────────────────────────────────────────────
data-dir=/var/lib/monero
log-file=/var/log/monero/monerod.log
log-level=0
max-log-file-size=104857600
prune-blockchain=1
sync-pruned-blocks=1
# ── P2P: the only port the firewall opens ─────────────────
p2p-bind-ip=0.0.0.0
p2p-bind-port=18080
out-peers=32
in-peers=48
no-igd=1
# ── RPC A: unrestricted, loopback only, for you ───────────
rpc-bind-ip=127.0.0.1
rpc-bind-port=18081
# ── RPC B: restricted, what a wallet is allowed to ask ────
rpc-restricted-bind-ip=127.0.0.1
rpc-restricted-bind-port=18089
# ── misc ──────────────────────────────────────────────────
zmq-pub=tcp://127.0.0.1:18083
db-sync-mode=safe
Los dos receptores RPC son la parte que merece la pena entender. El puerto 18081 responde a todo, incluidas las llamadas administrativas, y está vinculado al loopback, que es donde debe estar. El puerto 18089 es la interfaz restringida: llamadas de solo lectura, sin componentes internos sensibles para la privacidad, y es lo que expone todo nodo público de la red. Aquí, ambos están en 127.0.0.1 a propósito: el paso 05 alcanza el 18089 a través de un túnel en lugar de abrirlo.
/etc/systemd/system/monerod.service
[Unit]
Description=Monero full node
After=network-online.target
Wants=network-online.target
[Service]
User=monero
Group=monero
Type=simple
ExecStart=/usr/local/bin/monerod --config-file /etc/monerod.conf \
--non-interactive
Restart=on-failure
RestartSec=30
TimeoutStopSec=300
KillSignal=SIGINT
StandardOutput=journal
StandardError=journal
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
[Install]
WantedBy=multi-user.target
KillSignal y TimeoutStopSec no son decoración. La base de datos necesita cerrarse limpiamente, y un demonio matado en seco a mitad de una escritura puede volver necesitando una reparación, o una resincronización. SIGINT le pide que se apague correctamente, y cinco minutos es el periodo de gracia para dejarle terminar. Toda guía que omite estas dos líneas está a un reinicio desafortunado de un fin de semana perdido.
systemctl daemon-reload
systemctl enable --now monerod
systemctl status monerod --no-pager
El demonio ahora recorre la cadena desde el bloque génesis, comprobando cada firma en anillo y cada prueba de rango que encuentra. En NVMe con unos pocos núcleos, eso es un día o dos; está limitado por la CPU y el disco, no por el ancho de banda, así que una conexión más rápida no lo acortará. Este trabajo es el producto entero. Un nodo que se lo saltara no sería más que una forma más lenta de confiar en otra persona.
Obsérvelo desde una segunda shell. La línea de estado le indica la altura, el número de pares y el tiempo restante estimado, y es toda la monitorización que la mayoría de los nodos llegan a necesitar:
monerod --rpc-bind-port 18081 status
journalctl -u monerod -f --no-pager
df -h /var/lib/monero # check this one more often than you think you need to
No importe una cadena de bloques descargada. Hay archivos en internet que prometen saltarse la espera, e importar uno convierte un nodo que usted verificó en un nodo que se cree un archivo que le dio un desconocido. Anula la única cosa por la que vino aquí. Si el tiempo de sincronización es realmente inaceptable, la solución honesta es una máquina con más núcleos, no un atajo alrededor de la verificación.
La trampa del demonio bootstrap. monerod puede responder a las consultas del monedero desde un nodo público mientras su propia sincronización se pone al día, lo cual es una comodidad con un filo peligroso: mientras esté activa, el tráfico de su monedero lo está sirviendo exactamente el tipo de tercero que esta guía existe para eliminar. Si la activa para tener algo funcionando en la primera hora, ponga un recordatorio en su calendario y desactívela en el momento en que su propia altura alcance la punta. Un compromiso temporal que nadie se acuerda de terminar no es más que la configuración antigua con un nombre nuevo.
Cuando la altura deja de moverse y coincide con un explorador de bloques de su confianza, el nodo está en marcha. A partir de aquí, el demonio le cuesta unos pocos gigabytes de tráfico al día, algo de CPU, y ninguna atención adicional más allá de las actualizaciones.
La interfaz RPC restringida está vinculada al loopback, lo que significa que ahora mismo no es accesible desde ningún sitio. Ese es el valor por defecto correcto, y el resto de este paso trata de elegir cómo cruzar esa brecha. Elija uno: combinan mal entre sí y solo necesita uno.
Opción A · Túnel SSH — una máquina, cero configuración. La respuesta correcta si usa un solo portátil. No se instala nada nuevo, nada nuevo escucha, y el túnel muere con la sesión. Su monedero apunta entonces a 127.0.0.1:18089 como si el nodo fuera local.
ssh -N -L 18089:127.0.0.1:18089 monero-vps
# leave it running; point the wallet at 127.0.0.1:18089
Opción B · WireGuard — varios dispositivos, siempre activo. La respuesta correcta para un teléfono, más un ordenador de sobremesa, más un portátil. El nodo se une a su red privada y los monederos lo direccionan por su IP de túnel, sin ningún puerto expuesto a internet. La guía de WireGuard construye el túnel; el único paso adicional aquí es dejar que el demonio responda a través de él.
# in /etc/monerod.conf
rpc-restricted-bind-ip=10.8.0.1 # the node's WireGuard address
confirm-external-bind=1
# and in the firewall, only on the tunnel interface
ufw allow in on wg0 to any port 18089 proto tcp
Opción C · Onion v3 — desde cualquier lugar, sin puerto, sin IP fija. La respuesta correcta si viaja, o si quiere que el nodo sea accesible sin ningún puerto de entrada en ningún sitio. Tor publica el servicio; no hay nada que redirigir ni nada que escanear. La guía del servicio oculto cubre el torrc completo; la parte específica del nodo son tres líneas.
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-rpc/
HiddenServiceVersion 3
HiddenServicePort 18089 127.0.0.1:18089
# then read the address Tor generated for you
cat /var/lib/tor/monero-rpc/hostname
Sea cual sea la puerta que haya construido, el lado del monedero son los mismos tres campos. En Feather: Settings → Node → add a custom node, host and port, y active el proxy de Tor si eligió el onion. En el Monero GUI oficial: Settings → Node → Remote node, con “connect to a remote node” seleccionado. En Cake Wallet: Settings → Nodes → add node, que acepta directamente una dirección onion. Si configuró un nombre de usuario y una contraseña en la interfaz RPC, los tres tienen campos para ello.
Después, compruebe que ha funcionado. El monedero debería mostrar la misma altura que su nodo, y el nodo debería mostrar un cliente RPC más. Si el monedero sigue actualizándose en un segundo justo, probablemente todavía esté hablando con el nodo público por defecto: la mayoría de los monederos mantienen el antiguo en la lista y vuelven a él en silencio.
Su monedero ya no entrega las transacciones a un desconocido: se las entrega a su propio demonio. Pero ese demonio se las anuncia después a sus pares desde la dirección IP de su servidor, y los pares toman nota. Monero ya distribuye una transacción nueva mediante una fase de retransmisión aleatorizada antes de propagarla, lo que dificulta identificar el primer salto; enviarla en su lugar por Tor elimina la cuestión por completo.
Basta una línea. El demonio sigue sincronizando bloques por la red normal —lo que mantiene la sincronización rápida— y enruta únicamente la difusión de sus transacciones salientes a través del puerto SOCKS local de Tor:
# in /etc/monerod.conf, with tor running locally
tx-proxy=tor,127.0.0.1:9050,16
Si quiere ir más allá y aceptar también pares por Tor, publique un segundo servicio oculto para el lado P2P e indique al demonio qué dirección onion debe anunciar. El número de puerto es cosa suya, siempre que ambas mitades coincidan y nada más en la máquina lo esté usando ya:
# /etc/tor/torrc
HiddenServiceDir /var/lib/tor/monero-p2p/
HiddenServiceVersion 3
HiddenServicePort 18084 127.0.0.1:18084
# /etc/monerod.conf
anonymous-inbound=YOUR_ONION_ADDRESS.onion:18084,127.0.0.1:18084
Ese paso ayuda más a la red que a usted, lo cual es una razón perfectamente válida para darlo. Cuesta algo de latencia y algunas plazas de pares, y significa que los nodos que solo usan Tor tienen dónde conectarse.
Opcionalmente: done un nodo público. Si dispone de ancho de banda y de disco, puede anunciar su punto de acceso RPC restringido para que los monederos de otras personas puedan usarlo. Es una contribución genuina a una red cuyo punto más débil es lo pocas personas que ejecutan su propio demonio, y viene con las obligaciones de cualquier servicio público: transportará el tráfico de otras personas y será visible como operador de nodo. Todos los planes de aquí incluyen ancho de banda no medido, así que lo primero es una decisión, no una factura.
# only if you mean it: expose the RESTRICTED port, never 18081
rpc-restricted-bind-ip=0.0.0.0
confirm-external-bind=1
public-node=1
# and open it: ufw allow 18089/tcp
Un nodo también es una buena compañía para otra infraestructura autoalojada: un nodo Lightning en el mismo rack, por ejemplo. Manténgalos en máquinas separadas si el presupuesto lo permite: tienen requisitos de tiempo de actividad distintos y procedimientos de recuperación muy diferentes.
El demonio se detiene, y la base de datos puede necesitar una pasada de reparación antes de volver a abrirse. Compruebe el espacio libre a diario durante la sincronización, y elija el tamaño del plan pensando en la cadena de dentro de tres años, no en la de hoy.
El puerto 18081 responde a llamadas administrativas. Su sitio es 127.0.0.1 para siempre. Si algo externo necesita alcanzar el nodo, llega al receptor restringido en el 18089, a través de un túnel.
Añadir su nodo a la lista no lo selecciona, y la mayoría de los monederos vuelven en silencio al nodo por defecto cuando este no está disponible. Compare las alturas y confirme que el nodo informa de un cliente RPC conectado.
Añadirlo más tarde no reduce una base de datos ya existente. Convertirla implica detener el demonio y ejecutar monero-blockchain-prune, que necesita horas y espacio de trabajo. Decídalo antes del primer arranque.
Se produjo una actualización de red y el demonio nunca se actualizó. No da voces: la altura sencillamente deja de coincidir con la realidad. Siga los anuncios de versiones y actualice antes de la altura de la bifurcación.
SIGKILL en mitad de una escritura, normalmente por una unidad de systemd sin KillSignal y con un tiempo de espera de parada corto. Use SIGINT, déle cinco minutos, y deje que el demonio cierre su propia base de datos.
Diez preguntas que surgen antes, durante y después de trasladar un monedero a un demonio que usted mismo ejecuta.
No. Los monederos de Monero escanean del lado del cliente: el monedero pide al nodo un rango de bloques, los descarga enteros e intenta descifrar cada salida localmente con su clave de vista privada. El nodo nunca recibe su clave de vista, su clave de gasto ni su dirección, y no puede saber cuáles de las salidas que acaba de entregarle son suyas. Esta es una diferencia arquitectónica real respecto a los monederos ligeros de Bitcoin, donde normalmente se le indica al servidor qué direcciones o scripts vigilar. Lo que un nodo remoto sí aprende es la capa de red: su dirección IP, el hecho de que un monedero en esa IP se está sincronizando, el rango de bloques que solicitó —que acota la altura de restauración de su monedero— y, lo más importante, cualquier transacción que le entregue para difundir. Esa última es la fuga que merece la pena cerrar.
Ejecute podado, salvo que tenga una razón para no hacerlo. Un nodo podado descarta siete octavos de los datos de firma en anillo de los bloques antiguos, conserva todo lo que un monedero o un par nuevo realmente necesitan de usted, sigue validando toda la cadena por sí mismo, y se queda en aproximadamente un tercio del disco de un nodo completo. Para un backend de monedero personal, el comportamiento es indistinguible. Ejecute un nodo completo si quiere poder servir a un nodo nuevo su propia sincronización inicial desde cero, si utiliza herramientas al estilo de un explorador de bloques que leen datos históricos de transacciones arbitrarios, o si simplemente quiere una copia de archivo completa. Decídalo antes de la primera sincronización: --prune-blockchain poda a la vez que sincroniza, mientras que convertir una base de datos completa ya sincronizada implica detener el demonio y ejecutar sobre ella la herramienta independiente monero-blockchain-prune.
Un nodo completo supera los 240 GB a mediados de 2026 y crece del orden de decenas de gigabytes al año, así que calcule el tamaño para la cadena que tendrá dentro de tres años, no la que tiene hoy. Un nodo podado ocupa aproximadamente un tercio de eso: digamos entre 85 y 95 GB ahora mismo. En la práctica, eso significa que un Garrison (240 GB NVMe) es el hogar cómodo para un nodo podado con años de margen, y que un Ravelin (480 GB) es la máquina adecuada para uno completo. Un Sentinel de 120 GB alojará hoy un nodo podado, pero le hará volver a pensar en ello antes de lo que le gustaría. Compruebe el tamaño actual de la cadena antes de comprar el disco: es la única cifra de esta guía que tiene garantizado quedarse desactualizada.
Un día o dos en NVMe para una primera sincronización, limitada por la CPU y el disco, no por su conexión. El demonio va verificando cada firma en anillo y cada prueba de rango desde el bloque génesis en adelante; ese es el trabajo, y es la razón por la que merece la pena ejecutar el nodo. Dos cosas lo empeoran drásticamente: un disco duro mecánico en lugar de NVMe, que puede convertir dos días en una semana, y quedarse sin espacio en disco a mitad de camino. Dos cosas que no ayudan tanto como cabría esperar: más ancho de banda y más RAM más allá de lo que mantiene calientes las páginas de la base de datos. No importe un archivo de cadena de bloques descargado de un tercero para saltarse la espera: estaría confiando exactamente en la parte en la que se propuso dejar de confiar.
La sin restringir, nunca. La interfaz RPC sin restringir expone llamadas administrativas, y debe permanecer vinculada a 127.0.0.1 durante toda la vida del nodo. La interfaz restringida es otra cosa: solo responde a las llamadas de solo lectura que necesita un monedero, y es lo que expone todo nodo público de la red. Aun así, publicarla en un puerto de la red normal anuncia “aquí hay un usuario de Monero” a cualquiera que escanee el espacio de direcciones. El orden de preferencia de esta guía es, primero, un servicio onion v3; segundo, un túnel WireGuard; tercero, un túnel SSH para una sola máquina; y un puerto público desnudo solo si ha decidido deliberadamente donar un nodo público a la red.
Un nodo no guarda claves, no custodia fondos y no puede mover el dinero de nadie. Valida bloques y retransmite transacciones que otras personas ya han firmado, la misma postura que un relé de correo que transporta mensajes que no puede leer. Esa es la realidad técnica; la realidad legal es jurisdiccional, y esta guía no es asesoramiento legal. Lo que sí cambia según la jurisdicción es quién puede obligar a qué: la guía sobre las cuatro jurisdicciones nórdicas repasa la normativa aplicable a un servidor ubicado en Estocolmo, Helsinki, Oslo o Reikiavik.
Solo si lo actualiza. Monero realiza actualizaciones de red programadas, y un demonio que ejecuta un conjunto de reglas de consenso antiguo deja de seguir la cadena principal en la altura de la bifurcación: no le avisa a gritos, simplemente se detiene o se bifurca por su cuenta, y su monedero informa en silencio de una altura que ya no coincide con la realidad. Suscríbase a los anuncios de versiones, fije la versión que instaló en lugar de seguir una etiqueta móvil, y ponga un recordatorio en el calendario para la altura de actualización anunciada. Esta es, con diferencia, la forma más habitual en que un nodo autoalojado deja de ser útil: no un fallo, sino un propietario que dejó de leer.
Enrute por Tor la difusión de sus transacciones salientes: es el único ajuste con un retorno de privacidad claro y barato, porque separa “esta transacción entró en la red” de “esta dirección IP existe”. Aceptar también pares entrantes de Tor es un paso más que ayuda más a la red que a usted, y cuesta algo de latencia. Enrutar por Tor todo el tráfico de pares es la opción agresiva: funciona, y hará su sincronización inicial considerablemente más lenta, así que la mayoría de la gente sincroniza por la red normal y después cambia a Tor la ruta de las transacciones. La guía del servicio oculto de Tor trata el lado del torrc con más profundidad.
Casi siempre, la altura de restauración. Un monedero sin altura de restauración, o con ella fijada en cero, vuelve a escanear la cadena desde el bloque génesis cada vez que se restaura, lo cual son horas de trabajo local para nada. Fije la altura de restauración en el bloque que existía cuando se creó el monedero. La segunda causa es la ruta de red: un monedero en otro país que habla con su nodo a través de un circuito onion saturado será más lento que el mismo monedero contra un nodo público de al lado; ese es el precio de la privacidad, y un túnel WireGuard suele recuperar casi toda la velocidad. La tercera, la que se le escapa a la gente, es que su nodo no ha terminado su propia sincronización inicial y todavía responde desde un demonio bootstrap.
Porque un nodo es un objeto duradero y accesible públicamente, por el que pasan sus transacciones. Un nodo completo cierra la fuga entre su monedero y el nodo de un desconocido, y a cambio abre una más pequeña, entre su nodo y quien le alquiló la máquina. Si el alta de esa máquina llevó un escaneo de pasaporte y una tarjeta a su nombre legal, usted ha desplazado la correlación, no la ha eliminado. Pagar en Monero el servidor que ejecuta su nodo de Monero no es un eslogan; es la única versión de la configuración en la que las dos capas concuerdan entre sí. La guía principal sobre alojamiento VPS anónimo recorre las tres capas de principio a fin.
Garrison (4 vCPU, 8 GB, 240 GB NVMe, $7.90/mes) aloja un nodo podado con años de margen; Ravelin (480 GB) admite la cadena completa. Ancho de banda no medido en todos los planes, sin correo electrónico al darse de alta, sin documento de identidad, nunca.
Última revisión · 2026-10-12 · Fuentes · Guías de usuario de getmonero.org (ejecutar un nodo, poda, Tor e I2P), monerod --help en la línea v0.18, documentación de Debian 12 y del Tor Project · Cadencia · anual
This guide is one spoke of a larger series. The pillar walks the three privacy layers end to end — the sibling spokes below dive into the specifics.
Three independent layers — signup, payment, network — explained, legal context included, common mistakes flagged.
Your own LN node — bitcoind + LND or Core Lightning, on a VPS.
Accept Bitcoin and Lightning with no processor — non-custodial, no fees.
Deploy your own MCP server on a no-KYC VPS — TLS, streamable HTTP, OAuth.
Host an MCP server with no ID — the privacy stack, crypto-paid.
Alojamiento privado, construido en el Norte.