Einen Bitcoin-Lightning-Node selbst hosten.
Sechs Schritte. Ihr eigener LN-Router auf eigenem nordischem Metall.

Beschnitten (10–50 GB) für persönlichen Lightning-Betrieb — Sie brauchen nicht die vollständige Geschichte, um an Lightning teilzunehmen, Sie brauchen nur einen funktionierenden Bitcoin-Knoten. Vollständig (~700 GB und wachsend) wenn Sie auch historische Transaktionen verifizieren, einen Block-Explorer lokal betreiben oder zur Netzwerkresilienz beitragen wollen, indem Sie die Kette an andere Knoten bereitstellen. Die meisten persönlichen LN-Betreiber wählen beschnitten; Knoten-Betreiber-Hobbisten wählen vollständig.

LND wenn Sie das breiteste Ökosystem wollen — BTCPay Server, RTL, ThunderHub, mobile Fernsteuerungs-Wallets, der Großteil der Lightning-Entwicklerwerkzeuge. Core Lightning (CLN) wenn Sie die kleinere Codebasis, die Plug-in-Architektur, die C-Implementierung wertschätzen oder an der Bitcoin-Maximalist-Kultur teilnehmen, die sie bevorzugt. Beide Implementierungen interoperieren auf dem Lightning-Protokoll; Sie können später wechseln, indem Sie den Wallet-Seed in das andere wiederherstellen.

Ein praktisches Minimum liegt bei ~0,005 BTC. Das deckt einen oder zwei ausgehende Kanäle von je $100–200 plus On-Chain-Reserve für das Kanalmanagement ab. Darunter fressen Kanal-Öffnungs- und -Schließungsgebühren einen zu hohen Prozentsatz des Kapitals. Der ideale Bereich für jemanden, der lernt, liegt bei 0,01–0,05 BTC über drei bis fünf Kanäle mit gut vernetzten Knoten.

Technisch gesehen ja, wenn Sie den pruned-Modus und enge Speichereinstellungen verwenden, aber Sie werden ständig gegen die Ressourcengrenzen kämpfen. Sentinel ($5.90, 4 GB RAM) ist genug für einen pruned-Node + LND im Leerlauf, aber eng unter echtem Traffic. Ravelin ($23.90, 16 GB) ist komfortabel. Bulwark ($46.90, 32 GB, 960 GB Disk) ist das richtige Zuhause für einen unpruned-Vollknoten plus LND plus BTCPay.

Drei Maßnahmen. (1) bitcoind mit onlynet=onion und proxy=127.0.0.1:9050 konfigurieren — der gesamte ausgehende P2P-Traffic geht durch Tor. (2) LND mit tor.active=true und tor.v3=true betreiben, sodass auch der Kanal-Öffnungs-/Schließungsverkehr über Tor geht. (3) Die Clearnet-IP Ihres Nodes nicht in den Kanal-Öffnungs-Metadaten bewerben. Korrekt ausgeführt ist Ihr Node vollständig Tor-geroutet und nur die On-Chain-Kanal-Öffnungs-Transaktion ist öffentlich sichtbar.

Weniger als Sie denken mögen. Ein gut finanzierter Kanal mit einem guten Peer kann Monate ohne Eingriff bestehen. Die hauptsächliche Wartung: gelegentlich Liquidität neu ausbalancieren (ein-/ausgehende Routung), schließen und wieder öffnen, wenn ein Peer konsequent offline ist, und Gebühren bei Kanal-Schließtransaktionen während Hochgebühren-Mempool-Perioden erhöhen. Tools wie Balance-of-Satoshis (LND) oder summary.py (CLN) automatisieren das meiste davon.

Nein — Lightning erfordert, dass mindestens ein Kanal genug Kapazität auf der Empfängerseite hat. Entweder Kanäle ZU gut vernetzten Knoten öffnen (leicht kontraintuitiv — Sie öffnen ausgehend, sie haben eingehende Liquidität zu Ihnen), oder einen Liquiditätsdienst bezahlen (Bitrefill Thor, LNBig, Lightning Pool), um einen Kanal von ihnen zu Ihnen zu öffnen. Für den Empfang bedeutsamen Volumens sind ~0,05 BTC eingehend ein vernünftiges Startziel.

Zwei Überlegungen. (1) Wo der Server physisch steht — Schweden, Finnland, Norwegen, Island für das nordische Verfassungsregime; die Vertiefung ist unter /guides/nordic-jurisdictions-for-privacy-hosting/. (2) Ob das Betreiben eines LN-Nodes in Ihrem Wohnsitzland als Betreiber reguliert ist — die meisten EWR/EU-Länder behandeln selbst gehostete Nodes als persönliche Infrastruktur, nicht als regulierten Finanzdienstleister, aber einige haben Grauzonen. Die Jurisdiktion des Hosts schützt den Server; die Jurisdiktion des Betreibers regelt Ihre persönliche Haltung.