Cómo configurar tu nodo Bitcoin Core para que vaya rápido, ocupe lo justo y sea seguro — tanto si quieres soberanía personal como si lo usas para cobrar (BTCPay) o Lightning. Guía práctica y en cristiano, actualizada a 2026.
La primera decisión es la que más afecta al disco:
| Tipo | Disco | Para qué |
|---|---|---|
| Completo | ~650 GB (y creciendo) | Servir la cadena a otros, txindex, exploradores, máxima utilidad para la red |
| Podado (pruned) | ~10–100 GB (configurable) | Validar por ti mismo con poco disco. Wallets, BTCPay, Lightning. La mejor opción para la mayoría. |
Toda la configuración vive en bitcoin.conf, dentro del directorio de datos:
| Sistema | Ruta |
|---|---|
| Linux | ~/.bitcoin/bitcoin.conf |
| macOS | ~/Library/Application Support/Bitcoin/bitcoin.conf |
| Windows | %APPDATA%\Bitcoin\bitcoin.conf |
Tras editarlo, reinicia bitcoind (o Bitcoin Core) para aplicar los cambios.
Un bitcoin.conf equilibrado para un nodo podado moderno:
# --- Nodo podado (~50 GB) --- prune=50000 # MiB a conservar (~50 GB). 550 = mínimo dbcache=4000 # MB de RAM para la caché UTXO → acelera el sync maxmempool=300 # MB de mempool par=0 # hilos de validación (0 = auto, todos los núcleos) # --- Red --- listen=1 # aceptar conexiones entrantes (ayuda a la red) maxconnections=40 # nº de peers maxuploadtarget=5000 # MiB/día de subida (si tienes datos limitados) # --- RPC (para wallets / BTCPay / Lightning) --- server=1 rpcbind=127.0.0.1 # SOLO localhost (NUNCA 0.0.0.0) rpcallowip=127.0.0.1 rpcauth=usuario:hash$... # hash, NO contraseña en claro (ver §7)
| Parámetro | Qué hace | Recomendado |
|---|---|---|
dbcache | RAM para la caché del conjunto UTXO. Más caché = sincronización mucho más rápida. | 2000–8000 (alto durante el sync) |
prune | Tamaño de bloques a conservar (poda el resto). | 50000 (~50 GB), o 0 para completo |
txindex | Índice completo de transacciones. Incompatible con prune. Solo si lo pide tu app. | 0 (BTCPay/NBXplorer NO lo necesita) |
par | Hilos de verificación de firmas. | 0 (auto) o limita si compartes CPU |
blocksonly | No retransmite mempool (ahorra ancho de banda). No usar si una wallet necesita ver el mempool. | 0 (1 si vas justo de datos) |
assumevalid | Salta la validación de firmas hasta un bloque conocido-bueno (acelera el IBD). Trae uno por defecto. | dejar por defecto |
Para no exponer tu IP al usar el nodo (sobre todo con wallet), enruta por Tor:
proxy=127.0.0.1:9050 # SOCKS de Tor listen=1 onlynet=onion # solo conexiones por Tor bind=127.0.0.1
Bitcoin Core crea un servicio onion automáticamente si detecta el puerto de control de Tor (9051). Con onlynet=onion ganas privacidad a costa de algo de velocidad.
| Componente | Mínimo (pruned) | Recomendado (completo) |
|---|---|---|
| Disco | 256 GB SSD | 1 TB+ NVMe (HDD NO — demasiado lento) |
| RAM | 4 GB | 8–16 GB (más RAM → más dbcache → sync más rápido) |
| CPU | Raspberry Pi 4/5 | Cualquier x86 moderno / mini-PC |
| Red | Conexión estable | Sin límite de datos (el IBD baja ~650 GB) |
dbcache a 4000–8000 durante el sync (luego puedes bajarlo).assumevalid: la validación por defecto ya está optimizada.El error más común y peligroso es exponer el RPC. Reglas de oro:
rpcpassword en claro: genera un rpcauth con hash (script rpcauth.py oficial).rpcbind=127.0.0.1 y rpcallowip=127.0.0.1. Si una app remota necesita acceso, usa un túnel SSH, nunca abras el puerto 8332 a internet.| Uso | Configuración |
|---|---|
| Soberanía personal + wallet | Pruned 50 GB + Tor + RPC localhost |
| Cobrar (BTCPay) | Pruned + server=1 + RPC para NBXplorer (sin txindex) |
| Lightning (LND/Core Lightning) | Pruned o completo + server=1 + zmqpubrawblock/zmqpubrawtx |
| Explorador / servir la red | Completo + txindex=1 + disco grande |
rpcbind no esté en 0.0.0.0 y que el 8332 esté cerrado en el firewall.Precio, veredicto del día, funding, flujos ETF y cuenta atrás del halving — en vivo y en español.
Ver el panel en vivo →