Der Backup & Restore Leitfaden für Lightning Fullnodes

Der grosse Backup & Restore Leitfaden für alle Lightning Fullnodes Betreiber und die, es noch gerne werden wollen.

Betreiber mit einer Lightning Node kommen ab einer bestimmten Anzahl an Kanälen zwangsläufig zur Frage, wie man sich am besten , beziehungsweise die Node und die Kanäle darauf, bestmöglichst absichert, und die Kanäle nach einem Ausfall wieder herstellen kann. Das Thema ist etwas komplex, aber wir schauen uns heute an, wie wir eine Lightning Node am besten absichern können, und wie wir Kanäle bei einem Totalausfall wiederherstellen können. Hier gibt es nämlich ein paar Dinge, die sehr wichtig sind, und auch ein Paar Dinge, die man auf keinen Fall machen darf, wie ich es selber schmerzlichst lernen musste. Damit euch keine Fehler passieren, besprechen wir in diesem Artikel die wichtigsten Schritte.

Wir schauen uns die besten Strategie für die Systeme Raspiblitz, Umbrel und BTCPay Docker an. Ziel ist es eine möglichst sichere Umgebung für unsere Fullnode herzustellen, um in Falle eines Platten- oder Systemausfalls schnell wieder Online zu sein und gegebenfalls alle Kanäle wiederherzustellen. Wichtig zu verstehen ist, das aktuell noch keine reinen Datenbackups aktuell nicht möglich sind. Ihr könnt also nicht eure komplette Platte klonen oder backupen, und einen Server wieder herstellen falls es zu einem Ausfall kommt.

Hintergründe und wichtiges zuerst bei Single Disk Deployments

Es gibt einige Verwirrung und Mythen darüber, wie man Off Chain Funds der eigenen Nodes am besten sichert. Ein Fehler hierbei stellt immer noch das größte Risiko dar, diese Gelder zu verlieren, obwohl alles getan wird, um diese Risiken zu minimieren. Es gibt nur ein Szenario, bei dem man das Guthaben sichert, und auf einer neuen Node wieder komplett wieder herstellen kann, inklusive allen Kanälen, und zwar dann, wenn der Server noch nicht abgeschmiert ist. In den meissten Fälle ist es aber eher umgekehrt: Der Server beziehungsweise die Node ist tot, und ihr steht da wie vom Blitz getroffen.

Welche Daten dürfen in regelmässigen backups gesichert werden

Die wichtigste Datei, die immer gesichert werden muss, ist die Datei <lnddir>/data/chain/bitcoin/mainnet/channel.backup. Diese Datei enthält die Statischen Kanal-Backups (SCBs). Sie wird nur aktualisiert, wenn die Node gestartet wird und wenn ein Kanal geöffnet oder geschlossen wird. Alle anderen Dateien auf der Node sind mehr oder weniger egal.

Die meisten Lightning-Wallet-Apps wie die WalletofSatoshi oder Phoenix laden diese Datei automatisch in die Cloud hoch.

Wie wir diese Datei sichern, und bei einem Ausfall der Node verwenden, um unsere Kanäle wiederherzustellen, schaue wir uns weiter unten dann genau an.

Welche Dateien sollte man nicht in regelmässigen Backups sichern

Das ist eine etwas trickreiche Frage, denn das Anfertigen des Backups ist nicht das Problem. Das Wiederherstellen/Verwenden einer alten Version der channel.db zu finden unter <lnddir>/data/graph/mainnet/ ist sehr riskant und sollte niemals gemacht werden!

Das erfordert etwas Erklärung:

Die Art und Weise, wie LN-Kanäle derzeit eingerichtet sind (bis eltoo/SQL) implementiert wird), ist, dass beide Parteien immer einem aktuellen Saldo zustimmen. Um sicherzustellen, dass keiner der beiden Peers in einem Kanal jemals versucht, einen alten Zustand dieses Saldos zu veröffentlichen, geben sie beide ihre Schlüssel an den anderen Peer weiter. Dies gibt ihm die Möglichkeit, alle Gelder (nicht nur ihren vereinbarten Anteil) aus einem Kanal zu nehmen, wenn ein falscher oder veralteter des Channelstates veröffentlicht wird. Daher bedeutet das Vorhandensein eines alten Kanalzustands im Grunde, dass man den Saldo an die andere Partei verlieren kann.

Da Zahlungen in LND mehrmals pro Sekunde getätigt werden können, ist es sehr schwierig, jedes Mal ein Backup der Kanaldatenbank zu machen, wenn sie aktualisiert wird. Und selbst wenn es technisch möglich ist, kann das Vertrauen, dass ein bestimmter Zustand sicher der aktuellste ist, nie absolut sein. Deshalb sollte der Fokus darauf liegen, sicherzustellen, dass die Kanaldatenbank (also die channel.db) nicht beschädigt wird, die Zombie-Kanäle zu schließen und die SCBs sicher aufzubewahren.

Ausnahmefall noch laufende Node

Kommen wir zur Ausnahme, wann eine Node doch von einem kompletten Backup wiederhergestellt werden darf: Im Ausnahmefall, und nur wirklich in diesem speziellen Fall darf man den kompletten /.lnd Ordner (in der sich die channel.db befindet) sichern, und zwar genau dann, wenn die Node noch nicht den Geist aufgegeben hat. Das komplett Backup darf also nur erzeugt werden, wenn die Node direkt nachher offline genommen wird. Raspiblitz bietet dazu die Funktion LNDRESCUE, oder die komplette Migration an, die Scripte erstellen Backups welche beim aufsetzen einer neuen Node später verwendet werden, um alle Guthaben inklusive aller Kanäle, wieder herzustellen.

LND Rescure sichert nur die Lightning Node, während das Migrationsbackup eure komplette Node sichert, inkls installierter Anwendungen und Einstellungen der Node.

Die Node wird direkt nach dem erstellen des Backups vom System selber offline genommen und heruntergefahren. BTCPay bietet ein ähnliche funktion, Umbrels OS bietet dagegen keine vollständige Sicherung von LND an. Bereitet euch also immer auf euer jeweiliges System gut vor!

Die mit Abstand beste Sicherung eurer Node

Die einfachste Methode, eure Lightning Node, beziehungsweise eure Kanäle zu sichern, ist ein einfaches RAID1 Setup. Damit sichert ihr euch gegen ein Plattenausfall ab, und könnt bei einem Plattenausfall die Node ganz normal weiterlaufen lassen, bis ihr einen Ersatz für die ausgefallene Platte habt. Das bietet sich aber leider nicht auf dem Pi4 an, da das Netzteil zu schwach ist, 2 SSDs über das Standard Netzteil zu betreiben. Habt ihr Umbrel, den RaspiBlitz oder BTCPay Docker aber auf einem Linux Server System, empfiehlt es sich hier unbedingt eine zweite Platte zu nutzen. Dabei empfiehlt es sich, wirklich das komplette System auf dem RAID Verbund zu haben, damit das System auch gesichert wird.

Ist es bei einem Single Disk Setup zu einem Crash eurer Node gekommen, schauen wir uns jetzt die wichtigsten Methoden an, um unsere Onchain sowie auch Kanalguthaben, falls vorhanden, wiederherzustellen. Fangen wir doch gleich mit dem Ausnahmefällen an, und zwar dann, wenn die Node noch nicht gecrasht ist.

Wiederherstellung aus Backups

Raspiblitz Backup & Restore mit LNDRESCUE

Der Raspiblitz kommt mit einer äusserst nützlichen komplett Backup & Restore namens LNDRESCUE. Dabei wird eine komplette Sicherung des gesammten .lnd Ordners durchgeführt. Heisst also, ihr könnt diese Funktion nutzen, wenn die Node noch nicht komplett abgestürzt ist, eure Festplatte bald voll ist, oder andere Dinge passiert sind die eine Neuinstallation bzw. ein Transfer voraussetzen. LNDRESCUE fährt auch eure Node nach dem Backup automatisch herunter nachdem ihr das Backup heruntergeladen habt. Dabei kann beinahe fast nichts schiefgehen

Wichtig ist, dass möglichst zur selben Raspi Version migriert wird, und es keine grossen Versionsunterschiede gibt. Falls auf dem alten System noch eine 1.90 läuft, und ihr das neuste Image flasht, wie zum Beispiel 1.11, dann stehlt sicher, dass die alte Node vorher auch noch geupdated wird!

Backup Starten

Geht in das CLI Menü des Raspiblitzes mit menu und geht in die Repair Options, danach Backup / Repair LND und wählt danach Backup your LND data (Rescue-File) aus:

Der Raspi startet danach eine umfassende Sicherung der Lightning Node und stellt euch am Schluss einen Befehl zur Verfügung, der euch die Datei von einem Windows- oder Linux Rechner herunterladen lässt. Autocompackt Channels könnt ihr aktivieren, um die Grösse etwas zu reduzieren. Danach ladet ihr euch mit den entsprechenden Links die Backups herunter:

Ladet die Datei herunter, bestätigt danach mit Enter, da die Node anschliessend heruntergefahren wird.

LNDRescue Backup Wiederherstellen

Nachdem ihr eine frisch installierte Node habt, könnt ihr nun die alte Node mit LNDRESCUE komplett wiederherstellen. Heisst auch den LND Seed, die Kanäle und eure komplette Transaktionshystorie. Dafür müsst ihr auch nicht warten, bis eure Node komplett wieder synchronisiert ist. Startet den Pi mit einem frischen Image auf einem frischen Hardwaresetup. Die LNDRESCUE Datei habt ihr optimalerweise bereits auf einem USB Stick gespeichert. Diesen benötigen wir für den LNDRESCUE Restore:

Wählt hier Restore from a rescue file aus. Im nächsten Fenster könnt ihr das Backup eurer frischen Raspiblitz Installation getrost überspringen. Folgt den Anweisungen der Konsole, und gebt den Pfad zu eurem LNDRESCUE Backup an. Das Backup wird eingespielt, die Node anschliessend neugestartet. Ihr könnt, falls ihr bereits synchronisiert seid, danach direkt eure Kanäle wieder verwenden

Raspiblitz komplette Migration auf ein neues Gerät

Wie bereits erwähnt, haben wir dazu ein eigenes Tutorial geschrieben. Dies könnt ihr nutzen, falls eure Node noch funktioniert, und ihr sie auf ein komplett neues Gerät übertragen wollt:

BTCPay Server Backup & Restore Funktion benutzen

Der BTCPay Server in der eigenständigen Docker Variante kommt mit einen eigenen Backup and Restore Script welches ihr im Home Verzeichnis von vom BTCPay Server also unter btcpayserver-docker/btcpay-backup.sh findet. Wollte ihr eure Blockchain Daten sichern, müsst ihr das separate tun z.B rsync oder direkt auf eine Sicherungsplatte.

Skript Sicherung durchführen

Loggt euch als root user ein gebt folgendenden Befehl ein:

cd $BTCPAY_BASE_DIRECTORY/btcpayserver-docker
./btcpay-backup.sh

Das Skript wird folgende Schritte durchführen:

1. Sicherstellen, dass der Datenbank-Container läuft.
2. Ein Backup (Dump) der Datenbank erstellen.
3. Den BTCPay Server stoppen.
4. Die Docker-Volumes und das Datenbank-Backup archivieren.
5. Die Blockchain-Blöcke und Chainstate-Verzeichnisse ausschließen.
6. Optional: Das Archiv verschlüsseln.
7. Den BTCPay Server neu starten.
8. Aufräumen: Temporäre Dateien wie das Datenbank-Backup entfernen.

Falls alles klappt, seht Ihr folgendes: ✅ Backup done => /var/lib/docker/volumes/backup_datadir/_data/backup.tar.gz

Die Datei nackup.tar.gz könnt ihr auf einem USB Stick oder auf einem anderen Medium speichern um später wieder herzustellen falls der Server die komische Anzeichen macht oder ihr auch beispielsweise einfach das System migrieren möchtet. Ihr könnt auch das Backup mit rsync z.B auf ein anderes Netzwerkgerät syncen und sichern. Fahrt den Server nach Sicherung der Datei auf ein Medium, oder auf einen Netzwerkspeicher herunter.

Skript Wiederherstellung

Ähnlich zum Skript btcpay-backup.sh aber umgekehrt: der btcpay-restore.sh Skript muss mit der Pfadangabe ausgeführt werden. also z.B

./btcpay-restore.sh /mnt/usb/backup.tar.gz

Bei einem erfolgreichem Restore bekommt Ihr: ✅ Restore done

Bedenkt dabei, dass bei einem Restore die Kanäle ebenfalls wiederhergestellt werden, und deshalb der Server direkt nach dem erstellen des Backups unbedingt heruntergefahren werden muss!

On Chain Guthaben wiederherstellen

Dies ist der einfachste und unproblematischste Schritt auf allen 3 System. Um eure Onchain-Guthaben zu sichern, braucht ihr nur den Seed bzw. die 24 Wörter für eure Bitcoin-Core Wallet oder eure Lightning On-Chain Wallet. Sollte ein System ausfallen, müsst ihr nichts anderes tun, als die Seedphrase eingeben und ihr habt eurer Guthaben zurück. Das betrifft nochmals gesagt, nur Guthaben, die nicht in Lightning Kanälen sind!

Umbrel Node

Beim Aufsetzen einer neuen Node kann beim ersten Zugriff auf die Lightning Node eine neue Wallet erstellt werden, oder eine Wallet aus einer Seedphrase wiederhergestell werden. Um uer Onchain Guthaben wieder herzustellen, müsst ihr eure Seedphrase eingeben, die ihr beim erstellen eurer Lightning Wallet erstmalig aufgeschrieben habt.

Wählt also RECOVER YOUR PREVIOUS NODE aus, und gebt danach eure 24 Wörter ein. Damit habt ihr die Onchain Funds eurer Node wiederhergestellt. Hattet ihr vorher diverse Lightningkanäle, springt zur Umbrel Kanal Wiederherstellung um die Kanäle wieder her zu stellen.

BTCPay Server Docker

BTCPay Docker verfügt über mehrere Wallets, eine Shop Wallet, welches eine reine Onchain Wallet ist, und die Lightning Wallet auf der Lightning Node. Beide müssen separate wiederhergestellt werden.

Die Bitcoin Shop Wallet wiederherstellen

Um die Bitcoinn Shop Wallet wiederherzustellen, klickt einfach auf den Bitcoin Button links in der Menüspalte und klickt danach auf connect an exisiting Wallet

Auf der nächsten Seite habt Ihr die Möglichkeit, die Art der Wiederherstellung auszuwählen:

Habt ihr keine Wallet File, müsst ihr eure Wallet Adresse manuel eingeben. Macht das am besten auf einem frischen System bei dem ihr wisst, dass ihr womöglich keine bösartige Software oder Viren drauf habt. Ihr könnt die Guthaben natürlich auch auf einer Software Wallet wie Sparrow wiederherstellen. Diese könnt ihr dann auf ein frisch erstellte Wallet auf dem BTCPay Server senden.

LND Wallet wiederherstellen

Die oben vorgestellte Backup Methode vom BTCPay Server stellt auch eure LND Wallet wieder her, solltet ihr also ein Backup erstellt haben, könnt ihr damit eure Wallet wiederherstellen. Falls ihr kein Backup habt, und nur eure 24 Wörter für die LND Wallet, folgt dem folgendem Leitfaden:

Das Wiederherstellen der Lightning Wallet beim reinem BTC-Pay Server ist etwas umständlich. Die Wiederherstellung der LND Wallet geschieht auf der Kommandozeile.

Der anfängliche Ausgangspunkt, um die Wiederherstellung von On-Chain-Geldern über die Kommandozeile auszulösen, ist der Befehl lncli create.

lncli create

Als Nächstes kann man ein neues Wallet-Passwort eingeben, um alle neu abgeleiteten Schlüssel als Ergebnis des Wiederherstellungsprozesses zu verschlüsseln. Diesen Schritt könnt ihr mit Enter überspringen.

Input wallet password:
Confirm wallet password:

Sobald ein neues Wallet-Passwort erstellt wurde, werdet ihr aufgefordert, die vorhandenen Chiffrierschlüssel (Cipher Seed) einzugeben:

Input your 24-word mnemonic separated by spaces: ability noise lift document certain month shoot perfect matrix mango excess turkey river pitch fluid rack drill text buddy pool soul fatal ship jelly

Wenn beim Erstellen des Seeds ein Passwort für den Chiffrierschlüssel verwendet wurde, MUSS es jetzt eingegeben werden:

Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase):

Schließlich habt ihr die Möglichkeit, ein Wiederherstellungsfenster zu wählen:

Input an optional address look-ahead used to scan for used keys (default 2500):2500

Das Wiederherstellungsfenster ist ein Maß, das der On-Chain-Scanner verwendet, um zu bestimmen, wann alle "benutzten" Adressen gefunden wurden. Wenn das Wiederherstellungsfenster zu niedrig ist, wird LND keine Gelder in Adressen finden, die nach dem Punkt erzeugt wurden, an dem zwei aufeinanderfolgende Adressen generiert, aber nie verwendet wurden. Wurde eine LND On-Chain-Wallet umfangreich genutzt, möchtet ihr möglicherweise den Standardwert erhöhen.

Sollten alle bereitgestellten Informationen gültig sein, wird euch der Seed erneut präsentiert:

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

---------------BEGIN LND CIPHER SEED---------------
 1. ability   2. noise   3. lift     4. document
 5. certain   6. month   7. shoot    8. perfect
 9. matrix   10. mango  11. excess  12. turkey
13. river    14. pitch  15. fluid   16. rack
17. drill    18. text   19. buddy   20. pool
21. soul     22. fatal  23. ship    24. jelly
---------------END LND CIPHER SEED-----------------

!!!YOU MUST WRITE DOWN THIS SEED TO BE ABLE TO RESTORE THE WALLET!!!

lnd successfully initialized!

Danach habt ihr eure Onchain Funds erfolgreich auf dem BTCPay Server wiederhergestellt. Wie hier die Kanäle wiederherstellt erfahrt ihr weiter unten.

Raspiblitz Fullnode

Der Raspiblitz hat nur eine LND Wallet mit Onchain Funds. Deshalb gehts gleich weiter, wie die LND Wallet wieder hergestellt werden kann. Vorausetzung dafür ist ein frisch installiertes Blitzimage, und ein synchronisierter Bitcoincore Client. Die Node muss also vollständig synchronisiert sein, damit die Funds wieder auftauchen.

LND Onchain Wallet wiederherstellen

Achtung: diese Option ist nur auszuwählen, falls ihr keine Kanäle hattet! Weiter unten findet ihr die Anleitung um Kanäle wiederherzustellen. Das Raspiblitzmenu bietet im Menu eine extra Option an, um nur die Onchain Funds der LND Wallet wiederherzustellen. Loggt euch per SSH auf dem wiederhergestellten RaspiBlitz ein und begebt euch mit dem Befehl menu ins CLI Menü des Blitzes, dort wählt ihr dann Repair Options und danach Repair/Backup LND:

Im nächsten Fenster wählt Ihr dann Restore from a seed (onchain funds only)

Im nächsten Fenster fragt euch der Blitz ob ihr LND vorher sichern wollt, da ihr neu aufgesetzt habt, müsst ihr nichts sichern, könnt also einfach mit <skip> fortfahren. Anschliessend startet der Blitz die entsprechende Konfiguration. Ihr könnt dann in den folgenden Schritten euren alten LND Azeed eingeben. Folgt einfach den Anweisungen.

Offchain Guthaben oder Lightning Kanäle sichern

Wir kommen nun zu dem Teil des Tutorials, der euch zeigt, wie ihr eure Kanäle mit der wichtigen, euch nun bereits bekannten SCB Datei channel.backup, sichert.

Die SCB-Datei in LND (Lightning Network Daemon) steht für "Static Channel Backup". Sie ist quasi die Lebensversicherung bei einem Totalausfall des Lightning Knotens. Die grösste Konzentration liegt darauf, dass diese Datei unter allen Umständen regelmässig gesichert werden muss.

Hier wichtige Details zur SCB-Datei:

1. Zweck der SCB-Datei: Die SCB-Datei ist dazu gedacht, Informationen über eure Lightning-Kanäle zu speichern, allerdings in einer statischen Form. Das bedeutet, sie speichert die grundlegenden Infos zu den Kanälen, wie die Kanal-IDs und die Knoten, mit denen ihr verbunden seid.
2. Nutzung im Notfall: Die Hauptfunktion der SCB-Datei ist die Wiederherstellung eurer Kanäle im Falle eines Totalausfalls eures Knotens, wie z.B. bei einem Hardwarefehler oder Datenverlust. Wenn ihr also einen neue LND Node aufsetzt, könnt ihr die SCB-Datei verwenden, um eure Kanäle wiederherzustellen.
3. Limitationen: Es ist wichtig zu verstehen, dass die SCB-Datei nicht dazu dient, Kanäle "am Leben zu erhalten" oder den aktuellen Zustand eurer Kanäle zu sichern. Sie hilft nur bei der Wiederherstellung der Existenz der Kanäle, nicht aber bei der Wiederherstellung des Kanalzustandes oder der Transaktionshistorie. Nach der Verwendung der SCB Datei, werden also alle ehemaligen Kanäle zwangsgeschlossen, und ihr bekommt eure Lightning Guthaben nach eineriger Zeit zurück. Das heißt, sie ist eine Art Sicherheitsnetz, aber keine umfassende Backup-Lösung.
4. Vorsichtsmaßnahmen: Es ist entscheidend, dass ihr die SCB-Datei sicher und getrennt von eurem Knoten aufbewahrt. Sollte jemand unbefugt Zugriff darauf erhalten, könnte dies ein Sicherheitsrisiko darstellen. Zusammen mit dem Seed kann eurer gesammtes Lightning Guthaben abgegriffen werden.

Zusammenfassend ist die SCB-Datei in LND also das wichtigste Werkzeug für die Notfallwiederherstellung eurer Lightning-Kanäle bei einem Ausfall eurer Node. Sie ist jedoch kein Allheilmittel und kann nicht den laufenden Betrieb oder den aktuellen Zustand Eurer Kanäle sichern. Es ist also wichtig, zusätzlich zu den SCB-Backups auch andere Vorsichtsmaßnahmen zu treffen, um die Sicherheit eurer Lightning-Kanäle zu gewährleisten.

Umbrel SCB Datei sichern

die SCB Datei findet ihr auf der Umbrel Lightning Node oben rechts unter den 3 Strichen:

Die Datei könnt ihr direkt downloaden und an einem Ort eurer Wahl speichern. Eine Automatische Sicherung gibt es nicht, wie die Einstellung Automatic backups suggeriert! Zumindest finde ich nirgends eine Option aus einem Online Backup von Umbrel wiederherzustellen.

BTCPay Server Docker SCB Datei sichern

Auf dem BTCPay Server gibt es keine automatische SCB Backup Funktion, deshab machen wir uns einen eigenen Script, der die channel.backup regelmässig bei Änderungen sichert, ähnlich bzw gleich der SCB Backup Funktion des Blitzes.

LND backup script für die channel.backup mit inotify

Installiert euch zuerst das Tool inotify auf dem Host.

sudo apt install inotify-tools

Skript erstellen

Erstellt einen Script der die channel.backup Datei überwacht mit nano /pfad/copy-channel-backup-on-change.sh mit folgendem Inhalt:

#!/bin/bash

# Pfade und Einstellungen
SOURCE_FILE="/var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup"
BACKUP_PATH="/backuppfad/channel.backup"
DELAY=10  # Verzögerung in Sekunden nach Erkennung von Änderungen

while true; do
    # Warte auf eine Änderung (modify) an der Datei
    inotifywait -e modify $SOURCE_FILE
    
    # Warte nach der Erkennung einer Änderung
    echo "$(date): Modification detected. Waiting for $DELAY seconds before copying..."
    sleep $DELAY

    # Kopiere die Datei zum Backup-Pfad
    cp $SOURCE_FILE $BACKUP_PATH

    echo "$(date): File copied to $BACKUP_PATH"
done

Bitte passt den BACKUP_PATH an einen enstsprechenden Pfad an (z.B an einen gemounteten USB Stick oder einen Netzwerkspeicher)

Macht die Datei ausführbar mit:

chmod +x /pfad/copy-channel-backup-on-change.sh

als Service hinzufügen

Erstellt eine neue Service Datei mit sudo nano /etc/systemd/system/backup-channels.service mit folgenden Inhalt:

[Service] 
ExecStart=/pfad/copy-channel-backup-on-change.sh 
Restart=always 
RestartSec=1 
StandardOutput=syslog 
StandardError=syslog 
SyslogIdentifier=backup-channels 
User=ubuntu 
Group=ubuntu 
[Install] 
WantedBy=multi-user.target

Den Dienst startet ihr mit:

sudo systemctl start backup-channels

Überwachen könnt ihr in mit:

journalctl -fu backup-channels

Beim booten des Servers den Service automatisch mit starten:

sudo systemctl enable backup-channels

rsync backup mit crontab

Eine einfache Variante ist auch das sichern dern SCB Datei mit einem einfach rsync cronjob. Dafür braucht ihr keine Scripte und keinen extra Service, ist aber nicht ganz so sauber wie die inotify methode.

Erstellt einen crontab mit sudo crontab -e mit folgendem Inhalt:

15 * * * * rsync -avz /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup /mnt/usbstick/

Damit wird die SCB Datei alle 15 Minuten auf den Stick gesichert. Ihr könnt natürlich auch das besagte NFS Share benutzen oder einen externen ftp/sftp Host verwenden.

Raspiblitz SCB Datei sichern

Lokale Sicherung

Für den Raspiblitz gibt es eine automtische Backup Funktion der SCB Datei (channel.backup) unter Funktion im Raspiblitz Menu. Dies findet ihr unter Node Settings & Options:

Hier könnt ihr die SCB über auf ein USB Speicher speichern. Habt ihr eine Nextcloud, wäre dies natürlich auch eine Option.

Ihr könnt einen UBS Stick an der Node lassen, oder auf einen nfs Share sichern, zb. einem Netzwerkspeicher. Wie sowas funktioniert, erfahrt ihr z.B hier. Der Raspi oder der ist dann einfach der NFS Client. Am einfachsten wäre aber für den Heimgebrauch die USB Stick Methode die an einen entsprechenden Ort gemountet wird.

Ihr müsste dafür ein USB Stick an euren Raspiblitz anstecken, welcher als Speicherort für das Backup dient. Nach der Ausführung des Dienstes SCB/Emergency Backup führt der Blitz die Sicherung regelmässig bei der Änderung der SCB Datei durch.

Fügt den Stick nach Ausführung des SCB/Emergency Backup tools noch unbedingt in die Datei fstab mit ein, damit der Stick automatisch beim erneuten starten der Node, an den richtigen Ort gemounted wird. Schaut mit lsblk, nach dem ausführen des Services bitte nach, wo der Stick gemounted wurde ist. Der Stick muss in der Datei fstab unter /mnt/backup gemounted werden. Benutzt dazu am besten die UUID. Wie das funktioniert, erfahrt ihr am Ende des nächsten Abschnittes.

Der nächste Abschnitt aktiviert die Auto Backup Funktion über die Kommandozeile, und fügt den Stick mit in die Datei /etc/fstab mit hinzu:

Manuelle Konfiguration Auto-SCB Backup

Für die manuelle Konfiguration des Autobackup der SCB Datei via USB Stick, geht ihr am besten so vor:

Stick am PI einstecken

Am Blitz via SSH anmelden und mit CTRL+C auf die Shell wechseln.
Prüfen, ob er einen verwendbaren Stick erkannt hat:

sudo ./config.scripts/blitz.backupdevice.sh status

ungefähre Ausgabe wäre

blitz.backupdevice.sh
backupdevice=0
backupCandidate[0]='sdb 7 GB JetFlash'
backupCandidates=1

Backup aktivieren:

sudo ./config.scripts/blitz.backupdevice.sh on

Im erscheinenden Dialog FORMAT wählen

Prüfen, ob der Stick unter /mnt/backup eingehangen ist:

sudo ./config.scripts/blitz.backupdevice.sh mount

UUID Ausfindig machen und in die Datei /etc/fstab hinzufügen

UUID des Sticks anzeigen lassen (Achtung! Das ist mein Stick - sieht bei euch anders aus)

Entweder ganz einfach via

blkid

oder den Status des Services nochmals abrufen nachdem ihr das Backup manuel aktiviert habt:

sudo ./config.scripts/blitz.backupdevice.sh status

Ausgabe wäre:

blitz.backupdevice.sh
backupdevice=1
UUID='1B08-0CE4'
isMounted=1

UUID kopieren und /etc/fstab editieren:

sudo nano /etc/fstab

In der Datei am Ende diese Zeile einfügen (hier wieder eure UUID eintragen):

UUID='1B08-0CE4' /mnt/backup vfat defaults 0 2

Datei speichern mit strg+o ,Y und ENTER. Beenden mit strg+x

Jetzt wird der Stick nach einem reboot automatisch gemountet und ein Backup der channel.backup erstellt sobald diese sich bei einer Channel State modifzierung verändert.

Remote Sicherung

In einer Nextcloud

Via Nextcloud könntet ihr eure SCB Datei auch remote sichern, schaut dazu in diesem gesonderten Beitrag vorbei:

Backups via Netzwerkanbindungen direkt z.b. mit NFS

Schaut mal hier vorbei, wie ihre z.B einen Ordner aus eurer Synology direkt auf einem Linux System mounten könnt.

Wiederherstellung Lightning Kanäle mit SCB

Diese Methode kommt zur Anwendung, wenn eure Node durch einen Plattenausfall verloren ist, oder aus anderen Gründen nicht mehr wiederherzustellen ist. Ihr benötigt dafür die channel.backup und eure LND Seed.

Seit Version v0.6-beta besitzt lnd ein Feature namens Statische Kanal-Backups (SCBs). Diese sind statisch, da sie nur einmal benötigt werden: beim Erstellen des Kanals. Ein Backup bleibt gültig, bis der Kanal geschlossen wird. Es enthält alle notwendigen Informationen, um die Datenverlustschutz-Funktion (DLP) im Protokoll zu aktivieren, was letztlich zur Wiederherstellung der Gelder des Kanals auf der Blockchain führt. Dies ist ein ausfallsicherer Backup-Mechanismus.

Dieser Weg gilt als sicher, weil darauf geachtet wurde, dass es keine Fallstricke gibt, wie es beispielsweise beim regelmäßigen Kopieren der channel.db Datei der Fall sein könnte. Solche Methoden können riskant sein, da man nie sicher weiß, ob man den neuesten Stand eines Kanals hat. Stattdessen bieten SCBs eine einfache, sichere Methode, um Nutzern die Wiederherstellung der Gelder in ihren Kanälen, im Falle eines teilweisen oder vollständigen Datenverlusts, zu ermöglichen. Die Backups selbst sind mit einem Schlüssel verschlüsselt, der aus dem Seed der Wallet abgeleitet ist. Dadurch können andere beim klau der channel.back Datei nicht einfach Eure Kanäle auf anderen Nodes wiederherstellen.

Voraussetzungen für einen erfolgreichen SCB

Der Peer muss online sein, ist der Peer nicht online, bewirkt der Befehl nichts, da dieser voraussetzt, dass der Peer mit dem wir Kanäle hatten, online ist und auf unseren Restore-Anfrage reagiert. Ausserdem müsst ihr eure channel.backup bereits auf das jeweilige Systen geladen haben. Die kann z.B. vom regelmässig gesicherten channel.backup USB-Stick kommen, oder ihr habt diese aus eurem Netzwerkspeicher bereits zurück auf das System transferiert.

Was passiert bei einem SCB Restore

In dem gegebenen Prozess zur Wiederherstellung von Kanälen wird der Server eine Reihe von "Kanal-Kerndaten" in die Datenbank einfügen. Diese enthalten nur die Informationen, die notwendig sind, um das Datenverlustschutz-Protokoll (DLP) zu starten, und nichts weiter. Als Ergebnis werden sie in der Datenbank als "wiederhergestellte" Kanäle markiert (ChanStatusLocalDataLoss|ChanStatusRestored), und es wird nicht zugelassen, sie für andere Prozesse zu verwenden.

Sobald die Kanal-Kern Daten wiederhergestellt sind, versucht das Chanbackup-Paket, einen LinkNode einzufügen, der alle früheren Adressen enthält, mit der unsere Node den Peer erreichen kann.

LND startet dann wie üblich und versucht, Verbindungen zu allen Peers herzustellen, mit denen wir offene Kanäle hatten. Läuft LND bereits, wird ein neuer, beständiger Verbindungsversuch initiiert.

Sobald wir eine Verbindung zu einem Peer herstellen, startet das DLP-Protokoll. Der entfernte Peer wird feststellen, dass wir Daten verloren haben, und dann sofort seinen Kanal zwangsschließen. Bevor er dies tut, sendet er jedoch die Nachricht für den Kanal-Wiederherstellungshandshake, welchen wir benötigen, um Schlüssel abzuleiten um zu beweisen das wir die originalen Besitzer sind.

Sobald die Verpflichtungstransaktion bestätigt ist, leitet unsere Node, basierend auf den Informationen im SCB, alle benötigten Schlüssel neu ab um die Guthaben dann zu bergen.

SCB Wiederherstellung mit Raspiblitz

Seid euch im klaren dass das Recovern mit SCBs einer der letzte Massnahme darstellt, um seine Kanäle bzw die Funds darin wieder zu bekommen. Beim Recovering Prozess werden alle Kanäle seitens der Peers geschlossen via forceclose. Alle Schritte gehen von einem frisch installierten RaspiBlitz Image aus, und dass die Node vollständig eingerichtet und synchronisiert ist.

Um die die Kanäle wiederherzustellen, müsst ihr in den LND Repair Options vom Blitz folgende Option verwenden:

Ein Backup müsst ihr im nächsten Fenster nicht erstellen, da ihr ja frischt installiert seid. In den folgenden Fenstern gebt Ihr Eure LND Seed an, und gebt dem Blitz an, wo Ihr Eure channel.backup gespeichert habt.

Nach der Eingabe des Seeds der LND Wallet, und dem lokalisieren der channel.backup wird der Raspiblitz den SCB Restore einleiten. Das kann je nach Anzahl Kanäle einige Zeit dauern. Die Kanäle tauchen dann wieder in der Übersicht z.B in RTL auf, stehen dann aber in der Pending Close Warteschlange. Die Closing TXs seht ihr auf eurer Node nicht aufgrund der Notfallwiederherstellung die damit einhergeht, da der Peer, und nicht ihr, einen Force Close auslösst. Die Guthaben tauchen erst auf, nachdem der Force Close bestätigt worden ist, und die blocks_until_maturity vorüber sind, und die Funds erfolgreich gesweept wurden sind.

SCB Wiederherstellung BTCPay Docker

Um Kanäle wiederherzustellen müssen wir zuerst die alte urpsrüngliche LND Onchainwallet wiederherstellen, und den Wiederherstellungsbefehl erfolgreich manuel ausführen. Wie ihr die LND Wallet wiederherstellt, habt ihr bereits hier erfahren. Springt nochmals zurück, falls ihr das noch nicht getan habt.

Auf dem BTC-Pay Server müssen wir die Wiederherstellung manuel via lncli ausführen. Dafür benötigen wir den Script, der die Befehle in den LND Docker Container schickt. Die Skripte befinden sich all im btcpay-docker Ordner.

Um einen SCB Restore auszuführen benötigen wir also den Befehl bitcoin-lncli.sh restorchanbackup und die SCB Datei auf dem Server.

Wir führen also folgenden Befehl aus:

lncli restorechanbackup --multi_file=/pfad/channel.backup

Das kann je nach Anzahl Kanäle eine weile Dauern. Bittet beachtet nochmals, dass ihr Weile warten müsst. Überprüft mit den Hinweisen hier, ob die Closing Transaktion vom Peer ins Netzwerk gesendet worden ist.

SCB Wiederherstellung Umbrel

Umbrel verfügt nicht über eine komplette Backup & Restore wie der RaspiBlitz oder BTCPay Docker. Das heisst es können nur die Kanäle via SCB gesichert und wiederhergestellt werden.

Die Wiederherstellung der Kanäle auf der Umbrel Node ist relativ einfach. Vorausetzung ist ebenso, dass die Node mit dem originalen Seed eurer alten Node wiederhergestellt worden ist. Gebt eure Seed ein nachdem ihr die Neue Lightning Node online habt, und wählt dann oben rechts die 3 Punkte. Wählt dann Recover Channels aus:

Die Node wird dann mit den Seeds und dem Channelbackup die Kanäle wiederherstellen. Dabei führt sie einfach nur lncli restorechanbackup aus. Nachdem die Umbrel Node die Kanäle wiederhergestellt hat, werden die Kanäle auftauchen, aber automatisch geschlossen, falls eure Peers den rescue Befehl eurer Node erhalten.

SCB Restore ausgeführt aber keine Schliessung in Sicht?

Als erstes sei zu erwähnen, dass bei erfolgreichem SCB keine Rückerstattungen angezeigt werden, bis die Closing Transaktion bestätigt worden ist. Laut Aussagen der LND Entwicklern ist das normal bei einem Recovery.

Die nächste Problematik: möglicherweise ist die die Transaktion nicht in den Mempool gewandert, wahrscheinlich, weil die commit-fee der Node des Peers zu niedrig angesetzt waren und sie in High-Fee Zeiten vom mempool gepurged werden. In einem High-Fee Environment schickt LND nur channel closes in den mempool, wenn die Fee grösser als die aktuelle Purging Rate ist. In diesem Fall muss der Peer kontaktiert werden, welcher die Transaktion anstossen muss. Trettet am besten mit dem Peer in Kontakt und sucht zusammen nach einer Lösung und ob der Peer den Kanal nochmals schliessen kann. Der Peer muss dies als Force-Close tun, und nicht als Cooperative-Close!

Eine ein weiteres Problem das wir weiter oben bereits angesprochen haben, ist das der SCB Restore nicht funktioniert, wenn der Peer nicht Online ist. Der SCB Restore lösst ein Notsignal aus, dass die Peers dazu veranlasst einen Force Close auszulösen. Falls der Peer offline ist, und im dümmsten Fall nicht mehr Online kommt ist das SCB Recovery wirkungslos.

Wie finde ich die Closing Transaktionen im mempool

Öffnet zuerst mal mit lncli pendingchannels oder auf dem btcpay Server mit bitcoin-lncli.sh pendingchannels die aktuelle Kanalübersicht und sucht euch den Kanal raus, den ihr untersuchen wollt. Hier sucht hier nach den Kanälen mit ChanStatusLocalDataLoss|ChanStatusRestored und dem gesuchten Guthaben. Wir benötigen den channel_point

Diesen Kanal geben wir auf https://mempool.space ein und suchen uns die Closing-Transaktion heraus. Dafür gehen wir auf die opening TX, und suchen danach nach einer unbestätigten Transaktion:

Nach einem Klick auf den Channel-Open sehen wir die darin enthaltene Adressen und Transaktionen und dort sollten wir die Closing Transaktion gleich zu oberst finden: Diese ist eine Multi-Sig Transaktion da wir via SCB Restore signiert haben, und der Peer mit seinen private Keys ausgelösst durch unsere Anfrage.

Bei sehr hohen Onchainfees kann es sehr lange dauern, bis die Transaktion durchgeht. Entweder man wartet bis die Transaktion durch ist, oder man hilft etwas nach. Wie das geht, erfahrt ihr jetzt:

Force Closing Transaktion nach SCB Restore mit zu niedrigen Fees anstossen

Dafür gibt es ein Set an Tools von den Lightning Entwicklern namens Chantools. Die Chantools von Lightning Labs sind ein Set an Werkzeugen für die Verwaltung und Wartung von Lightning Network Nodes. Sie bieten verschiedene Funktionen, die für Nutzer von Lightning Nodes nützlich sind. Die Tools können auf einem anderen Rechner laufen und müssen nicht auf der betroffenen Node installiert werden.

Die Installation ist vor allem für Anfänger wirklich etwas komplex aber machbar. Um chantools nutzen zu können, kompilieren wir uns das Tool am besten schnell selbst. Ihr benötigt dafür einen Linux Computer und eine aktuelle Linux Distribution basieren auf Debian/Ubuntu. Chantools lässt sich auch auf dem Blitz installieren, von einigen Usern habe ich jedoch erfahren, dass dies nicht immer fehlerfrei funktioniert.

Gebt den Befehl chantools auf dem Blitz in die Konsole ein, bekommt ihr eine Befehlsübersicht. Wenn nicht, kompilieren wir uns chantools auf einem anderen Linux Rechner, oder einer virtuellen Maschine eurer Wahl selber.

Chantools installieren

Um selber zu kompilieren müssen wir zuerst die Prammiersprache Go und den Compiler Make installieren. Das geht mit folgenden Befehlen:

sudo apt install golang-go
sudo apt install make

Führt danach noch folgenden Befehl in der Komandozeile aus:

export PATH=$PATH:/usr/local/go/bin

Ladet euch die chantools mit dem git Befehl herunter:

git clone https://github.com/lightninglabs/chantools.git

wechselt in den Ordner chantools den ihr heruntergeladen habt mit cd chantools, danach kompiliert ihr das Programm mit dem einfachen Befehl make install

Schiebt die ausführbare chantools Datei dann mit:

mv ~/go/bin/chantools /usr/local/bin/

an die richtige Stelle um den chantools Befehl direkt an jedem Ort der Konsole ausführen zu können.

Danach habt ihr die Chantools auf eurem Rechner installiert und könnt den Befehl direkt verwenden.

Chantools ausführen

Die Bedienung bzw der Befehl ist etwas komplex, und wir benötigen vorher einiges an Information und zwar:

chantools pullanchor \
  --sponsorinput txid:vout \  --> ein UTXO aus Eurer LND Wallet welcher bereits bestätigt worden ist
  --anchoraddr bc1q….. \      --> die 330sats grösse Adresse aus dem Channel Closing siehe unten
  --changeaddr bc1q….. \      --> eine neue Adresse aus Eurer LND Wallet (p2wkh) z.B via RTL generieren
  --feerate 30                --> die Feerate die neu effektiv angesetzt werden soll

Möglicherweise gibt es 2 Anchor Outputs mit der grösse von jeweils 330Sats, notiert euch falls ja, beide Adressen

Kommen wir zum Ausführen des Befehls. Alle Befehle müssen in den Befehl mit den Flaggen gesetzt werden. z.B so

chantools pullanchor --sponsorinput 052a4b3fc363e1a045baa010cd5bf99024cce1d40a9a78741460934fc580aced:0 --anchoraddr bc1q9xn9wthafk4
sgp3hnuuf79twe7mpm43uzukt09t9v0m8cs8hs3fsj80zwa --changeaddr bc1qpeha3xv0m6k4u72p5sdv3e2vxsunhjzrgyp3qv --feerate 100

Anmerkung zur Feerate da es sich hier um einen CPFP Anstoss handelt, gelten nicht die eingestellten Fees. Das Thema ist etwas komplex, merkt euch aber dass bei einer eingestellten Fee von 100, zirka 55% also etwas mehr als die Hälfte als effektive Feerate für die neue Transaktion ausgeführt wird. Dies kann je nach grösse der Transaktion aber varieren.

Das Programm wird euch nach eurer LND Seedphrase fragen. Gebt die Seedphrase ein, und falls ihr keine Passphrase habt, drückt bei der Passphrase Abfrage einfach auf Enter. Das Tool erstellt euch nun einen PSBT-Output für eure Node, auf welcher ihr dem Befehl dann absetzen müsst.

Falls die Generierung der PSBT fehl schlägt, benutzt die andere Anchor Adresse mit 330Sats. Keine Angst, es passiert nichts, da chantools merkt, wenn die andere Anchor Adresse nicht der eigenen LND Seed Wallet zugehörig ist.

Kopiert Euch die lange Zeichenfolge (PSBT), und loggt euch per SSH auf eurem Pi, dem BTCPay Server oder auf der Umbrel ein. Unter Umbrel müsst ihr, um lncli Befehle absetzen zu können, in den Docker Container wechseln (docker exec -it docker_id bash). Im Umbrel Appstore gibt es auch eine App mit der ihr direkt LND Befehle absetzen könnt:

Befolgt den Befehlen von chantools: gebt zuerst die PSBT aus dem chantools Programm ein

lncli wallet psbt finalize <psbt>

und dann:

lncli wallet publishtx <final_tx>

Ein, die final _tx ist die Transaktionsnummer die euch der Befehl wallet psbt finalize erstellt. Mit Enter setzt ihr das ganze ab, nun wird die Transaktionsgebühr aus dem UTXO, den ihr angegeben habt, erhöht.

Ihr erhaltet danach eine neue TX. Diese könnt ihr im z.B auf mempool.space eingeben und beobachten. Wird die Transaktion bestätigt, bekommt ihr eure Guthaben ohne weiters zutun zurück.

SCB durchgeführt aber der Peer ist nicht mehr online

Dies ist die allerletze Methode und sollte wirklich nur dann ausgeführt werden, wenn der Peer lange nicht mehr online war. Kommt der Peer Online, während wir versuchen die Transaktion mit einem alten State zu forceclosen, bekommt der Peer alle unsere Guthaben.

Dafür benötigen wir aber die channel.db aus dem abgestürzten System. Habt ihr diese nicht, funktioniert diese Methode hier nicht. Ausserdem benötigen wir wieder die chantools, welche wir uns auf einem System unserer Wahl installieren können.

Alten Channel State veröffentlichen falls Peer dauerhaft offline ist

Dafür müssen wir mit den chantools arbeiten, installiert, diese wie oben beschrieben, Falls noch nicht getan. Ausserdem benötigen wir die Datei channels.db, aus der gecrashten Node. Falls diese nicht mehr wiederherzustellen ist, könnt ihr diesen Abschnitt hier übersringen.

Kopie der Kanal-DB erstellen: Um sicherzustellen, dass wir auf die Kanal-DB zugreifen können, erstellen wir eine Kopie im sicheren Modus. Führt einfach folgenden Befehl aus:

chantools compactdb --sourcedb /pfad/zur/channel.db --destdb ./results/compacted.db

Wir gehen davon aus, dass die kompaktierte Kopie der Kanal-DB sich in ./results/compacted.db befindet für die folgenden Befehle.

chantools summary: Zuerst muss chantools den Zustand jedes Kanals in der Blockchain ermitteln. Dafür wird eine Blockchain-API (standardmäßig blockstream.info) abgefragt. Das Ergebnis wird in einer Datei namens ./results/summary-yyyy-mm-dd.json geschrieben. Diese Ergebnisdatei wird für den nächsten Befehl benötigt.

chantools --fromchanneldb ./results/compacted.db summary

chantools rescueclosed: Es ist möglich, dass die entfernten Peers einige der verbleibenden Kanäle bereits erzwungenermaßen geschlossen haben. Was wir jetzt tun, ist, die privaten Schlüssel zu finden, um unseren Anteil dieser Kanäle zu übernehmen. Dafür benötigen wir ein gemeinsames Geheimnis, das commit_point genannt wird und sich jedes Mal ändert, wenn ein Kanal aktualisiert wird. Wir haben die neueste bekannte Version dieses Punktes in der Kanal-DB. Der folgende Befehl versucht, alle privaten Schlüssel für Kanäle zu finden, die von der anderen Partei geschlossen wurden. Der Befehl muss wissen, auf welchen Kanälen er operiert, daher müssen wir die durch den vorherigen Befehl erstellte summary-yyy-mm-dd.json angeben:

chantools --fromsummary ./results/<summary-file-name>.json rescueclosed --channeldb ./results/compacted.db

Dies wird eine neue Datei namens ./results/rescueclosed-yyyy-mm-dd.json erstellen, die alle gefundenen privaten Schlüssel enthält und auch für den nächsten Befehl benötigt wird. Verwendet z.B. bitcoind oder das Electrum Wallet, um alle privaten Schlüssel zu übernehmen.

chantools forceclose: Dieser Befehl wird nun alle Kanäle schließen, von denen chantools annimmt, dass sie noch offen sind und deren Peers nicht mehr online sind. Dies wird erreicht, indem der zuletzt bekannte Kanalzustand aus der channel.db-Datei veröffentlicht wird. Bitte lies den vollständigen Warnungstext des forceclose-Befehls unten, da dieser Befehl eure Gelder gefährden kann, wenn der Zustand in der Kanal-DB nicht der aktuellste ist. Dieser Befehl sollte nur für Kanäle ausgeführt werden, bei denen der entfernte Peer lange mehr online war.

chantools --fromsummary ./results/<rescueclosed-file-vom-letzten-schritt>.json forceclose --channeldb ./results/compacted.db --publish

Dies wird eine neue Datei namens ./results/forceclose-yyyy-mm-dd.json erstellen, die für den nächsten Befehl benötigt wird.

Warte auf Timelocks: Der vorherige Befehl hat die verbleibenden offenen Kanäle geschlossen, indem er den Zustand deines Knotens des Kanals veröffentlicht hat. Durch das Design des Lightning-Netzwerks müsst ihr jetzt warten, bis die euch gehörenden Kanalgelder nicht mehr zeitlich gesperrt sind. Abhängig von der Größe des Kanals müsst ihr irgendwo zwischen 144 und 2000 Bestätigungen der Zwangsschließungstransaktionen abwarten. Führt den nächsten Schritt erst aus, nachdem der Kanal mit der höchsten csv_verzögerung so viele Bestätigungen seiner Schließungstransaktion erreicht hat. Ihr könnt dies überprüfen, indem ihr jede zwangsweise geschlossene Kanaltransaktion auf einem Block-Explorer (wie blockstream.info oder mempool.space zum Beispiel) nachschlagt. Öffnet die resultierende JSON-Datei des letzten Befehls (./results/forceclose-yyyy-mm-dd.json) und sucht jede TXID in "force_close" -> "txid" auf dem Explorer. Wenn die Anzahl der Bestätigungen gleich oder größer ist als der in "force_close" -> "csv_delay" für jeden der Kanäle angezeigte Wert, könnt ihr fortfahren.

chantools sweeptimelock: Sobald alle Zwangsschließungstransaktionen die Anzahl der Transaktionen erreicht haben, wie im JSON als csv_timeout gefordert, können diese zeitlich gesperrten Gelder nun übernommen werden. Verwendet den folgenden Befehl, um alle Kanalgelder an eine Adresse eurer Wallet zu übertragen:

chantools --fromsummary ./results/<forceclose-file-vom-letzten-schritt>.json sweeptimelock --publish --sweepaddr <bech32-addresse-aus-eurer-lnd-wallet>

Danach könnt ihr eure Wallets überprüfen, ob die Guthaben gutgeschrieben worden sind.

Backup & Restore auf ein anderes System

Ein sonderer Fall besprechen wir noch hier, hier könnt bei einem Node Crash, und falls schon lange gewünscht von Umbrel auf ein anderes System switchen, auf dem LND direkt läuft. Die Anleitung findet dazu hier:

https://github.com/indomitorum/Baremetal-Migration-LND

Was tun wenn gar kein Backup vorliegt und praktisch keine Daten vorhanden sind

Peer kontaktieren

Sollten absolut gar keine Backups vorliegen haben, ist noch nicht alles verloren. Versucht den Kanal-Peer zu erreichen auf irgendeine Art die euch einfällt. Dafür könnt ihr z.B https://lightningnetwork.plus/ nutzen, und dort die Node aufsuchen, und ihre eine Nachricht schicken, oder ihr nutzt die Seite auf dem sich Peers mit dem selben Problem anschreiben können: https://node-recovery.com/

Schaut unter Zombie Channel Recovery Matcher (alpha) nach und gebt eure Daten an, hat der Peer das selbe Problem, dass der Close nicht durchkommt und er auch Sats auf seiner Seite hat, wird er sicht mit etwas Glück auch hier registrieren. Falls ein Match instande kommt, werden die Daten beider Parteien durch den Maintainer der Seite zusammen geführt. Die Datenbank sucht nach Peers die beide ein Force Close hatten.

Peer erfolgreich kontaktiert, FC per remote ausgelösst

Ihr konntet euren Peer erreichen, und dieser hat den Force Close per remote durchgeführt. Da ihr keinen SCB Restore durchgeführt habt, weiss eure Nodes nichts mehr von irgendwelchen Kanälen und kann deswegen auch die Funds aus dem Force Close nicht sweepen. Wir müssen die Sats deshalb manuell sweepen, und auf eine Wallet Adresse unserer Lightning Node überweisen. Die Gelder in Force Close Transaktionen landen nämlich nicht automatisch auf der eigenen Wallet, nachdem der FC bestätigt worden ist.

Wir benötigt hier deshalb nochmals die chantools, und zwar die Funktion sweepremoteclosed:

Wir benötigen dafür unsere 24 Wörter der Lightning Node, und eine Adresse, auf denen die Funds landen sollen. Hier der Befehl mit seinen Optionen:

chantools sweepremoteclosed [flags]

Examples

chantools sweepremoteclosed \
	--recoverywindow 300 \
	--feerate 20 \
	--sweepaddr bc1q..... \
  	--publish

Options

      --apiurl string           API URL to use (must be esplora compatible) (default "https://blockstream.info/api")
      --bip39                   read a classic BIP39 seed and passphrase from the terminal instead of asking for lnd seed format or providing the --rootkey flag
      --feerate uint32          fee rate to use for the sweep transaction in sat/vByte (default 30)
  -h, --help                    help for sweepremoteclosed
      --publish                 publish sweep TX to the chain API instead of just printing the TX
      --recoverywindow uint32   number of keys to scan per derivation path (default 200)
      --rootkey string          BIP32 HD root key of the wallet to use for sweeping the wallet; leave empty to prompt for lnd 24 word aezeed
      --sweepaddr string        address to recover the funds to; specify 'fromseed' to derive a new address from the seed automatically
      --walletdb string         read the seed/master root key to use fro sweeping the wallet from an lnd wallet.db file instead of asking for a seed or providing the --rootkey flag

Der Daten welche wir brauchen: feerate, die sweepaddr (kann eine Adresse aus der Lightning Wallet sein, aber auch eine Adresse von einer anderen Wallet sein )und einen apiurl string der uns nicht Rate limitiert. Die Feerate ergibt sich aus den aktuellen mempool.space Transaktionsgebühren, wählt hier eine geeignet hohe Gebühr aus. Die sweepaddr ist die Adresse, auf der die Funds landen sollen. Generiert euch hier euch Bech32 Adresse zum Beispiel via RTL und schreibt euch diese auf. Die apiurl ist eher optional, aber wir nehmen hier eine andere, da die Standard API, die chantools verwendet, häufiger mal probleme macht. Machen wir uns an den Befehl:

chantools sweepremoteclosed --recoverywindow 300 --feerate 8 --sweepaddr bc1_adresse --apiurl=https://electrs.gugger.guru --publish

Hier bekommt die Meldung dass ihr eueren Azeed eingeben müsst:

2024-08-17 12:25:24.784 [INF] CHAN: chantools version v0.12.0 commit 
Input your 24-word mnemonic separated by spaces: ...
Input your cipher seed passphrase (press enter if your seed doesn't have a passphrase): 

Danach erklärt euch dass chantools Adressen gefunden hat, auf die ihr Zugriff habt, verwendet den Privatekey durch den angegeben Azeed um die Adressen zu sweepen und sendet sie an die von euch angegeben Adresse:

024-08-18 13:38:53.604 [INF] CHAN: Found 1 unspent outputs for address bc1qkvtux0xxxxxxxxxxxxxxxxxxs0ejm6z520sz4xkqe
2024-08-18 13:39:18.405 [INF] CHAN: Fee 443 sats of 4996530 total amount (estimated weight 443)
2024-08-18 13:39:18.426 [INF] CHAN: Published TX 53523ffc74fe7854298283a0f103f959742fc175efe478d0e100330b9609169c

Die Published TX könnt ihr nun in einen Mempool werfen, und warten bis sie bestätigt wird. Sobald die TX durch ist, sind die Sats wieder auf eurer Wallet.

Fake SCB restore durchführen

Eine weitere Möglichkeit, seine Funds zu retten, wenn der Peer noch Online ist, ist sich selber ein SCB File zusammen zu bauen. Dies besprechen wir in einem separaten Artikel. Verasst wird dieser von einem Kollegen in einem Gastbeitrag.

Abschluss

Ihr kennt nun die wichtigsten Mittel und Wege eure Lightning Node abzusichern und im Katastrophenfall wiederherzustellen. Mir war es wichtig, dass es im Netz einen Artikel gibt, in dem quasi alle Informationen enthalten sind, und Nutzer, in einer prekären Lage sich die Informationen nicht quer auf x verschiedenen Seiten zusammen suchen müssen. Im Anhang findet ihr nochmals alle Quellen, Links und Github Seiten, aus denen die Informationen stammen. Viel Erfolg!

Quellen

https://github.com/lightningnetwork/lnd/blob/master/docs/safety.md

https://github.com/lightningnetwork/lnd/blob/master/docs/recovery.md

https://docs.lightning.engineering/lightning-network-tools/lnd/disaster-recovery

https://node-recovery.com/

https://github.com/lightninglabs/chantools

https://gist.github.com/alexbosworth/2c5e185aedbdac45a03655b709e255a3

Dank an Zett für die Bereitstellung einiger Hinweise und Bilder auf dem RaspiBlitz!