Il suo nodo Bitcoin.
I suoi canali Lightning. Senza KYC, end-to-end.

Per un nodo di routing pagamenti e un frontend BTCPay, pruned=550 (~5 GB su disco) è perfettamente sufficiente — LND, CLN e BTCPay necessitano solo del set UTXO e dello storico recente di blocchi per validare e instradare. Pruned riduce il requisito di storage da circa 700 GB a un numero a una cifra di GB e il carico di IBD-poi-stare-al-passo da «settimane» a «giorni». Esegua l'archivio completo solo se ha un caso d'uso di ricerca o block-explorer che richiede accesso ai dati storici dei blocchi per altezza; altrimenti pruned vince su ogni asse operativo.

LND è la più diffusa (~70% del grafo pubblico Lightning), ha il più ampio ecosistema di tooling (Thunderhub, ride-the-lightning, Balance of Satoshis) e la migliore integrazione BTCPay. Core Lightning (CLN) è la codebase più conservativa, ha l'architettura plugin più pulita ed è quella che molti gestori-di-gestori di nodi adottano per ragioni di routing-business. Eclair è l'implementazione in Scala, vista principalmente dietro il wallet di ACINQ. Per un primo nodo, LND su un Garrison è il percorso a minor attrito; CLN è la scelta giusta se vuole spingere le prestazioni di routing e tiene all'estensibilità tramite plugin.

Tor-only (tor.active=true, nessun listener clearnet) è il default massimalista per la privacy — il suo nodo è raggiungibile solo come .onion, nessuna fuga di IP, nessuna impronta da port-scan. Clearnet + Tor (dual listener) offre migliore channel-discovery e minore latenza di routing al costo di esporre l'IP del nodo al grafo pubblico. La maggior parte degli operatori inizia in Tor-only perché il costo operativo di aprire una porta clearnet non è banale (firewall, porta 9735, attenta identificazione dei log LN-correlati) e migra al dual una volta che inizia davvero a interessarsi all'ottimizzazione delle routing fee.

Usi gli Static Channel Backups (SCB) — LND scrive `channel.backup` ad ogni apertura o chiusura di canale, e quel file è sufficiente per recuperare fondi on-chain (force-close dal lato della controparte) ma non per riprendere i canali. Spedisca `channel.backup` fuori dalla macchina ad ogni cambiamento (rclone verso Backblaze cifrato, o un piccolo script che carica su un VPS separato). L'unica regola che costa sat alle persone: non ripristini mai un vecchio `channel.db`. Ripristinare uno stato obsoleto innesca la transazione di giustizia della controparte e perde i fondi del canale. SCB è la via sicura.

Il wallet di un nodo di routing Lightning è per definizione necessariamente hot — le chiavi devono firmare gli HTLC commitment in tempo reale. La disciplina sta nel dimensionamento: tenga solo ciò che le serve per i saldi dei canali che gestisce, tratti il wallet del nodo di routing come liquidità operativa (non risparmi), e sposti regolarmente il saldo on-chain in eccesso verso cold storage. Per un piccolo operatore, $500-$2.000 nel hot wallet sono tipici; per un nodo di routing serio, il saldo hot riflette la capacità di canale impegnata.

Un nodo pruned su un Garrison con 4 vCPU / 8 GB / 240 GB NVMe completa l'IBD in ~24 ore su uplink da 1 Gbps — la maggior parte di quel tempo è validazione delle firme, che è CPU-bound. Un nodo full archival su un Ravelin (8 vCPU / 16 GB / 480 GB NVMe) completa in ~48 ore. L'NVMe conta: i dischi rotanti trasformano l'IBD in un affare di più giorni perché le scritture UTXO di Bitcoin Core sono estremamente random-IO-pesanti. NordBastion offre NVMe in ogni fascia.

Lo stack docker-compose di BTCPay Server prevede bitcoind + un'implementazione LN + nbxplorer + il livello web di BTCPay. Su un Ravelin può ospitare l'intero stack su una sola macchina per un piccolo commerciante (qualche migliaio di transazioni l'anno); su un Garrison la pressione è reale appena gli indici nbxplorer iniziano a macinare, quindi raccomandiamo di separare BTCPay su una seconda fascia — Garrison per il nodo, Sentinel per il reverse-proxy BTCPay verso il nodo via WireGuard. Entrambi i flussi sono KYC-free end-to-end.

La proposta di valore di Bitcoin è il regolamento senza permessi. Nel momento in cui la sua infrastruttura di routing gira su un hoster che conosce-il-suo-cliente, ha-fatto-l'AML, conserva-la-carta, lei ha re-introdotto un chokepoint — non a livello di protocollo, a livello di infrastruttura. Hosting KYC-free per infrastruttura di pagamenti KYC-free non è assolutismo; è rimuovere il punto in cui la catena di custodia per «chi gestisce questo nodo di routing» può essere sottoposta a citazione. Il protocollo è senza permessi; l'hoster dovrebbe essere almeno permissionless-friendly.