Votre propre nœud Bitcoin.
Vos propres canaux Lightning. Sans KYC, de bout en bout.

Pour un nœud de routage de paiements et une façade BTCPay, pruned=550 (~5 GB sur disque) est parfaitement suffisant — LND, CLN et BTCPay n'ont besoin que de l'ensemble UTXO et de l'historique récent des blocs pour valider et router. Le mode pruned ramène le besoin de stockage de ~700 GB à un chiffre d'un seul digit en GB et la charge IBD-puis-keep-up de « semaines » à « jours ». N'exécutez l'archival complet que si vous avez un cas d'usage recherche ou block-explorer qui nécessite l'accès historique aux données de bloc par hauteur ; sinon pruned gagne sur tous les axes opérationnels.

LND est la plus déployée (~70 % du graphe Lightning public), a le plus grand écosystème d'outillage (Thunderhub, ride-the-lightning, Balance of Satoshis) et le plus de finition d'intégration BTCPay. Core Lightning (CLN) est la base de code plus conservatrice, a l'architecture de plugins la plus propre, et c'est ce que beaucoup d'opérateurs-de-nœuds-professionnels exécutent pour des raisons de routing-business. Eclair est l'implémentation Scala, vue surtout derrière le wallet d'ACINQ. Pour un premier nœud, LND sur un Garrison est le chemin de moindre friction ; CLN est le bon choix si vous voulez pousser la performance de routage et tenez à l'extensibilité par plugins.

Tor-only (tor.active=true, pas de listener clearnet) est le défaut privacy-maximaliste — votre nœud n'est joignable qu'en tant que .onion, pas de fuite d'IP, pas d'empreinte au scan de ports. Clearnet + Tor (double listener) donne une meilleure découverte de canaux et une latence de routage plus basse au prix d'exposer l'IP de votre nœud au graphe public. La plupart des opérateurs commencent en Tor-only parce que le coût opérationnel d'ouvrir un port clearnet n'est pas trivial (pare-feu, port 9735, identification soignée des logs liés au LN) et passent au double une fois qu'ils tiennent réellement à l'optimisation des frais de routage.

Utilisez les Static Channel Backups (SCB) — LND écrit channel.backup à chaque ouverture ou fermeture de canal, et ce fichier suffit à récupérer les fonds on-chain (force-close du côté contrepartie) mais pas à reprendre les canaux. Expédiez channel.backup hors-machine à chaque changement (rclone vers un Backblaze chiffré, ou un petit script qui upload vers un VPS séparé). La règle qui coûte des sats : ne restaurez jamais un vieux channel.db. Restaurer un état périmé déclenche la justice transaction de la contrepartie et vous perdez les fonds du canal. SCB est le chemin sûr.

Le wallet d'un nœud de routage Lightning est nécessairement hot par définition — les clés doivent signer les engagements HTLC en temps réel. La discipline est le dimensionnement : ne gardez que ce dont vous avez besoin pour les soldes de canaux que vous opérez, traitez le wallet du nœud de routage comme la caisse (pas l'épargne), et déplacez l'excédent on-chain vers du cold storage à cadence régulière. Pour un petit opérateur, $500 à $2 000 dans le hot wallet est typique ; pour un nœud de routage sérieux, le solde hot reflète la capacité de canaux que vous avez engagée.

Un nœud pruned sur les 4 vCPU / 8 GB / 240 GB NVMe d'un Garrison termine l'IBD en ~24 heures sur un uplink 1 Gbps — l'essentiel de ce temps est de la validation de signature, qui est CPU-bound. Un nœud archival complet sur un Ravelin (8 vCPU / 16 GB / 480 GB NVMe) termine en ~48 heures. Le NVMe compte : les disques rotatifs transforment l'IBD en affaire de plusieurs jours parce que les écritures UTXO de Bitcoin Core sont extrêmement gourmandes en random-IO. NordBastion est en NVMe à chaque palier.

La stack docker-compose de BTCPay Server attend bitcoind + une implémentation LN + nbxplorer + le tier web BTCPay. Sur un Ravelin vous pouvez héberger toute la stack sur une seule machine pour un petit marchand (quelques milliers de transactions par an) ; sur un Garrison la pression est réelle dès que les index nbxplorer se mettent à brasser, nous recommandons donc de scinder BTCPay sur un second palier — Garrison pour le nœud, Sentinel pour BTCPay reverse-proxyant vers le nœud sur WireGuard. Les deux flux sont sans KYC de bout en bout.

La proposition de valeur de Bitcoin est le règlement sans permission. À l'instant où votre infrastructure de routage tourne chez un hébergeur qui a fait son KYC, fait son AML, garde votre carte au dossier, vous avez réintroduit un goulot — pas au niveau protocole, au niveau infrastructure. L'hébergement sans KYC pour des infrastructures de paiement sans KYC n'est pas de l'absolutisme ; c'est supprimer l'endroit où la chaîne de garde pour « qui exploite ce nœud de routage » peut être subpoenaée. Le protocole est sans permission ; l'hébergeur devrait au moins être permissionless-friendly.