Auto-hébergez un nœud Bitcoin Lightning.
Six étapes. Votre propre routeur LN sur du métal nordique en propriété.

Élagué (10 à 50 GB) pour le fonctionnement Lightning personnel — vous n'avez pas besoin de l'historique complet pour participer à Lightning, vous avez juste besoin d'un nœud Bitcoin fonctionnel. Complet (environ 700 GB et croissant) si vous voulez aussi vérifier les transactions historiques, faire tourner un explorateur de blocs localement, ou contribuer à la résilience du réseau en servant la chaîne à d'autres nœuds. La plupart des opérateurs LN personnels choisissent élagué ; les amateurs d'opérateurs de nœuds choisissent complet.

LND si vous voulez le plus large écosystème — BTCPay Server, RTL, ThunderHub, portefeuilles mobiles de contrôle à distance, la majorité des outils de développement Lightning. Core Lightning (CLN) si vous valorisez la plus petite base de code, l'architecture de plug-ins, l'implémentation en C, ou si vous participez à la culture Bitcoin maximaliste qui le préfère. Les deux implémentations interopèrent sur le protocole Lightning ; vous pouvez changer plus tard en restaurant la graine du portefeuille dans l'autre.

Un minimum pratique est d'environ 0,005 BTC. Cela couvre un ou deux canaux sortants de 100 à 200 $ chacun plus la réserve on-chain pour la gestion des canaux. En dessous, les frais d'ouverture et de fermeture de canal consomment un pourcentage trop élevé du principal. La zone idéale pour quelqu'un qui apprend est de 0,01 à 0,05 BTC répartis sur trois à cinq canaux avec des nœuds bien connectés.

Techniquement oui si vous utilisez le mode élagué et des paramètres mémoire serrés, mais vous vous battrez constamment contre les limites de ressources. Sentinel (5,90 $, 4 GB RAM) suffit pour un nœud élagué + LND en état inactif mais reste serré sous tout trafic réel. Ravelin (23,90 $, 16 GB) est confortable. Bulwark (46,90 $, 32 GB, 960 GB de disque) est l'hébergement idéal pour un nœud complet non élagué plus LND plus BTCPay.

Trois pratiques. (1) Configurez bitcoind avec onlynet=onion et proxy=127.0.0.1:9050 — tout le trafic P2P sortant passe par Tor. (2) Faites tourner LND avec tor.active=true et tor.v3=true pour que le trafic d'ouverture/fermeture de canaux passe également par Tor. (3) N'annoncez pas l'IP clearnet de votre nœud dans les métadonnées d'ouverture de canal. Correctement mis en place, votre nœud est entièrement routé via Tor et seule la transaction d'ouverture de canal on-chain est publiquement visible.

Moins que vous ne le pensez. Un canal bien alimenté avec un bon pair peut rester des mois sans intervention. La maintenance principale : rééquilibrer occasionnellement la liquidité (routage entrée/sortie), fermer et rouvrir si un pair est systématiquement hors ligne, et augmenter les frais sur les transactions de fermeture de canal pendant les périodes de mempool à frais élevés. Des outils comme Balance-of-Satoshis (LND) ou summary.py (CLN) automatisent la plupart de cela.

Non — Lightning exige qu'au moins un canal ait suffisamment de capacité côté récepteur. Soit ouvrez des canaux VERS des nœuds bien connectés (légèrement contre-intuitif — vous ouvrez sortant, ils ont de la liquidité entrante vers vous), soit payez un service de liquidité (Bitrefill Thor, LNBig, Lightning Pool) pour ouvrir un canal depuis eux vers vous. Pour recevoir un volume significatif, environ 0,05 BTC entrant est une cible de départ raisonnable.

Deux considérations. (1) L'emplacement physique du serveur — Suède, Finlande, Norvège, Islande pour le régime constitutionnel nordique ; l'analyse approfondie est disponible sur /guides/nordic-jurisdictions-for-privacy-hosting/. (2) Si l'exploitation d'un nœud LN est réglementée là où vous résidez en tant qu'opérateur — la plupart des pays EEE / UE traitent les nœuds auto-hébergés comme une infrastructure personnelle, pas comme un service financier réglementé, mais quelques-uns ont des zones grises. La juridiction de l'hébergeur protège le serveur ; la juridiction de l'opérateur régit votre posture personnelle.