Su propio nodo Bitcoin.
Sus propios canales Lightning. Sin KYC, de extremo a extremo.

Para un nodo de enrutamiento de pagos y un frontend BTCPay, pruned=550 (~5 GB en disco) es perfectamente suficiente — LND, CLN y BTCPay solo necesitan el conjunto UTXO y el historial reciente de bloques para validar y enrutar. El modo podado reduce el requisito de almacenamiento de ~700 GB a un solo dígito de GB y la carga de IBD-y-mantener-al-día de «semanas» a «días». Ejecute archivo completo solo si tiene un caso de uso de investigación o explorador de bloques que necesite acceso a datos históricos de bloques por altura; de lo contrario, el podado gana en todos los ejes operativos.

LND es el más desplegado (~70 % del grafo público de Lightning), tiene el mayor ecosistema de herramientas (Thunderhub, ride-the-lightning, Balance of Satoshis) y la mejor integración con BTCPay. Core Lightning (CLN) es la base de código más conservadora, tiene la arquitectura de plugins más limpia, y es lo que muchos operadores-de-operadores-de-nodos ejecutan por razones de negocio de enrutamiento. Eclair es la implementación en Scala, vista mayormente tras la cartera ACINQ. Para un primer nodo, LND en un Garrison es la vía de menor fricción; CLN es la elección correcta si quiere empujar el rendimiento de enrutamiento y le importa la extensibilidad de plugins.

Solo Tor (tor.active=true, sin listener clearnet) es el predeterminado privacista — su nodo es accesible solo como .onion, sin filtración de IP, sin huella de escaneo de puertos. Clearnet + Tor (listener dual) da mejor descubrimiento de canales y menor latencia de enrutamiento al coste de exponer la IP de su nodo al grafo público. La mayoría de los operadores empiezan solo con Tor porque el coste operativo de abrir un puerto clearnet no es trivial (cortafuegos, puerto 9735, identificación cuidadosa de los registros relacionados con LN) y pasan al dual una vez que realmente les importa la optimización de tarifas de enrutamiento.

Use Static Channel Backups (SCB) — LND escribe channel.backup cada vez que un canal se abre o cierra, y ese archivo es suficiente para recuperar fondos on-chain (force-close desde el lado de la contraparte) pero no para reanudar los canales. Envíe channel.backup fuera de la máquina en cada cambio (rclone a Backblaze cifrado, o un script diminuto que suba a un VPS separado). La única regla que cuesta sats a la gente: jamás restaure un channel.db antiguo. Restaurar un estado obsoleto desencadena la transacción de justicia de la contraparte y pierde los fondos del canal. SCB es la vía segura.

La cartera de un nodo de enrutamiento Lightning es necesariamente caliente por definición — las claves tienen que firmar compromisos HTLC en tiempo real. La disciplina es el dimensionamiento: conserve solo lo que necesite para los saldos de canal que opera, trate la cartera del nodo de enrutamiento como el flotante (no como los ahorros), y mueva el exceso de saldo on-chain al almacenamiento en frío con una cadencia regular. Para un operador a pequeña escala, $500–$2.000 en la cartera caliente es lo típico; para un nodo de enrutamiento serio, el saldo caliente refleja la capacidad de canal que ha comprometido.

Un nodo podado en los 4 vCPU / 8 GB / 240 GB NVMe de un Garrison completa el IBD en ~24 horas sobre un enlace de 1 Gbps — la mayor parte de ese tiempo es validación de firmas, que es CPU-bound. Un nodo de archivo completo en un Ravelin (8 vCPU / 16 GB / 480 GB NVMe) completa en ~48 horas. El NVMe importa: los discos giratorios convierten el IBD en un asunto de varios días porque las escrituras UTXO de Bitcoin Core son extremadamente intensivas en IO aleatoria. NordBastion es NVMe en cada nivel.

La pila docker-compose de BTCPay Server espera bitcoind + una implementación LN + nbxplorer + la capa web BTCPay. En un Ravelin puede alojar la pila entera en una máquina para un comerciante pequeño (unos pocos miles de transacciones al año); en un Garrison el aprieto es real una vez que los índices nbxplorer empiezan a removerse, por lo que recomendamos dividir BTCPay en un segundo nivel — Garrison para el nodo, Sentinel para BTCPay haciendo proxy inverso de vuelta sobre WireGuard al nodo. Ambos flujos son sin KYC de extremo a extremo.

La propuesta de valor de Bitcoin es la liquidación sin permisos. En el momento en que su infraestructura de enrutamiento corre en un proveedor que conoce-a-su-cliente, hizo-su-AML, mantiene-tarjeta-registrada, ha reintroducido un punto de estrangulamiento — no en la capa de protocolo, en la capa de infraestructura. El alojamiento sin KYC para infraestructura de pago sin KYC no es absolutismo; es eliminar el lugar donde la cadena de custodia para «quién opera este nodo de enrutamiento» puede ser objeto de citación judicial. El protocolo es sin permisos; el proveedor debería ser al menos amigable con la ausencia de permisos.