Ihr eigener Bitcoin-Knoten.
Ihre eigenen Lightning-Channels. KYC-frei, end-to-end.

Für einen Payment-Routing-Knoten und ein BTCPay-Frontend ist pruned=550 (~5 GB auf der Platte) vollkommen ausreichend — LND, CLN und BTCPay benötigen nur das UTXO-Set und die jüngste Blockhistorie, um zu validieren und zu routen. Pruned senkt den Speicherbedarf von ~700 GB auf einstellige GB und den IBD-dann-dranbleiben-Workload von „Wochen“ auf „Tage“. Führen Sie vollarchivierende Knoten nur aus, wenn Sie einen Forschungs- oder Block-Explorer-Anwendungsfall haben, der historischen Zugriff auf Blockdaten nach Höhe benötigt; sonst gewinnt pruned auf jeder operativen Achse.

LND ist die am häufigsten eingesetzte Implementierung (~70 % des öffentlichen Lightning-Graphen), hat das größte Tooling-Ökosystem (Thunderhub, ride-the-lightning, Balance of Satoshis) und den besten BTCPay-Integrationsschliff. Core Lightning (CLN) ist die konservativere Codebasis, hat die sauberste Plugin-Architektur und ist das, was viele Knoten-Betreiber-von-Betreibern aus Routing-Geschäftsgründen betreiben. Eclair ist die Scala-Implementierung, meist hinter ACINQs Wallet anzutreffen. Für einen ersten Knoten ist LND auf einem Garrison der reibungsärmste Pfad; CLN ist die richtige Wahl, wenn Sie Routing-Performance auf die Spitze treiben wollen und Wert auf Plugin-Erweiterbarkeit legen.

Nur Tor (tor.active=true, kein Clearnet-Listener) ist die datenschutzmaximalistische Standardeinstellung — Ihr Knoten ist nur als .onion erreichbar, kein IP-Leak, kein Port-Scan-Fußabdruck. Clearnet + Tor (Dual-Listener) bietet bessere Channel-Discovery und geringere Routing-Latenz auf Kosten der Offenlegung Ihrer Knoten-IP im öffentlichen Graphen. Die meisten Betreiber starten mit Nur-Tor, weil der operative Aufwand des Öffnens eines Clearnet-Ports nicht trivial ist (Firewall, Port 9735, sorgfältige Identifizierung LN-bezogener Logs), und wechseln zu Dual, sobald sie sich tatsächlich für die Routing-Gebühren-Optimierung interessieren.

Verwenden Sie Static Channel Backups (SCB) — LND schreibt channel.backup, sobald ein Channel geöffnet oder geschlossen wird, und diese Datei reicht aus, um On-Chain-Mittel wiederherzustellen (Force-Close von der Gegenseite), nicht jedoch, um die Channels fortzusetzen. Versenden Sie channel.backup bei jeder Änderung außerhalb der Maschine (rclone zu verschlüsseltem Backblaze oder ein kleines Skript, das auf einen separaten VPS hochlädt). Die eine Regel, die Sats kostet: niemals eine alte channel.db wiederherstellen. Das Wiederherstellen eines veralteten Zustands löst die Justice-Transaktion der Gegenseite aus, und Sie verlieren die Channel-Mittel. SCB ist der sichere Pfad.

Die Wallet eines Lightning-Routing-Knotens ist per Definition zwingend hot — die Schlüssel müssen HTLC-Commitments in Echtzeit signieren. Die Disziplin liegt in der Dimensionierung: Halten Sie nur das, was Sie für die von Ihnen betriebenen Channel-Salden brauchen, behandeln Sie die Routing-Knoten-Wallet als Float (nicht als Ersparnisse) und verschieben Sie überschüssiges On-Chain-Guthaben regelmäßig in Cold Storage. Für einen kleinen Betreiber sind $500–$2.000 in der Hot-Wallet typisch; für einen ernsthaften Routing-Knoten spiegelt der Hot-Saldo die von Ihnen zugesagte Channel-Kapazität wider.

Ein pruned Knoten auf den 4 vCPU / 8 GB / 240 GB NVMe eines Garrison schließt IBD in ~24 Stunden über einen 1-Gbps-Uplink ab — der Großteil dieser Zeit ist Signaturvalidierung, die CPU-gebunden ist. Ein vollarchivierender Knoten auf einem Ravelin (8 vCPU / 16 GB / 480 GB NVMe) schließt in ~48 Stunden ab. Das NVMe ist entscheidend: Drehende Festplatten machen IBD zu einer mehrtägigen Angelegenheit, weil die UTXO-Schreibvorgänge von Bitcoin Core extrem random-IO-lastig sind. NordBastion ist auf jeder Stufe NVMe.

Der docker-compose-Stack von BTCPay Server erwartet bitcoind + eine LN-Implementierung + nbxplorer + die BTCPay-Web-Schicht. Auf einem Ravelin können Sie den gesamten Stack für einen kleinen Händler (ein paar Tausend Transaktionen pro Jahr) auf einer Maschine hosten; auf einem Garrison wird die Enge real, sobald die nbxplorer-Indizes anfangen zu arbeiten, daher empfehlen wir, BTCPay auf eine zweite Stufe aufzuteilen — Garrison für den Knoten, Sentinel für das BTCPay-Reverse-Proxying zurück über WireGuard zum Knoten. Beide Flows sind end-to-end KYC-frei.

Bitcoins Wertversprechen ist erlaubnisfreie Abwicklung. Sobald Ihre Routing-Infrastruktur auf einem Hoster läuft, der Know-Your-Customer betrieben, AML durchgeführt und eine Karte hinterlegt hat, haben Sie wieder einen Engpass eingeführt — nicht auf der Protokollebene, sondern auf der Infrastrukturebene. KYC-freies Hosting für KYC-freie Zahlungsinfrastruktur ist kein Absolutismus; es entfernt die Stelle, an der die Sorgepflichtkette für „wer betreibt diesen Routing-Knoten“ per Vorladung erzwungen werden kann. Das Protokoll ist erlaubnisfrei; der Hoster sollte zumindest erlaubnisfrei-freundlich sein.