Der Backup & Restore Leitfaden für Lightning Fullnodes

Der 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 zum Punkt, wie man sich am besten , bzw die Node und die Kanäle darauf bestmöglich absichern, und die Kanäle wieder herstellen kann, im Falle eines Totalausfalls des Systems. Das Thema ist etwas komplex. 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 wichtig zu wissen 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 Plattenausfalls schnell wieder Online zu sein und gegenfalls alle Kanäle wiederherzustellen. Wichtig zu wissen 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. Wir wir unsere Node also am besten sichern, und anschliessend wiederherstellen, schauen wir uns in den nächsten Zeilen genauer an.

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 eine Möglichkeit, wie man das Guthaben sichert, und auf einer neuen Node wieder herstellt, und zwar darf der Server noch nicht abgeschmiert sein, was in den meissten Fällen wo eher unwahrscheinlich ist. Der Server bzw 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, wenn sie sich ändert, ist die Datei <lnddir>/data/chain/bitcoin/mainnet/channel.backup. Diese Datei enthält die Statischen Kanal-Backups (SCBs). Sie wird nur aktualisiert, wenn der lnd gestartet wird, ein Kanal geöffnet oder geschlossen wird. Alle anderen Dateien auf der Node sind mehr oder weniger egal.

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

Wie wir diese Datei verwenden, um unsere Kanäle bei einem Totalausfall 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 altenVersion 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 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 alter Zustand veröffentlicht wird. Daher bedeutet das Vorhandensein eines alten Kanalzustands im Grunde, dass man den Saldo an die andere Partei verliert.

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 sichern, und zwar genau dann, wenn die Node noch nicht den Geist aufgegeben hat. Das Backup darf also nur erzeugt werden, wenn die Node direkt nachher offline genommen wird. Dies funktioniert aber auch nur sicher, wenn ein Restore auf extakt dem selben Setup mit dem selben Betriebssystem gesichert wird. Raspiblitz bietet dazu die Funktion LNDRESCUE, der Script erstellt ein Backup welcher beim aufsetzen einer neuen Node später verwendet werden, um alle Guthaben inkl Kanäle wieder herzustellen. Die Node muss aber, direkt nach dem erstellen des Backups offline genommen werden. BTCPay bietet ein ähnliche funktion, Umbrels OS bietet dagegen keine vollständige Sicherung von LND an. Bereitet also alles gut vor!

Die mit Abstand beste Sicherung Eurer Node

Die einfachste Methode, Eure Lightning Node, bzw 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 habt. Das bietet sich aber leider nicht auf dem Pi 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 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 Komplett 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

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 zuerst herunter, bestätigt danach mit Enter, da die Node anschliessend heruntergeladen werden muss.

Tipp

Sichert Euch zuerst die Blockchain bevor Ihr LNDRESCUE ausführt, das erspart Euch sehr viel Zeit damit Ihr bei der Neuinstallation nicht wieder neu synchronisieren müsst. Hier der Link zum entsprechenden Artikel.

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, falls er Euch fragt, dass noch Daten auf der Platte zu finden sind, stellt diese nicht wieder her da ansonten die Kanaldaten im schlechtesten Fall auch wiederhergestellt werden. Die LNDRESCUE Datei habt Ihr optimalerweise bereits auf einem USB Stick gespeichert. Diesen benötigen wir für den LNDRESCUE Restore:

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

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 und womöglich bald abschmiert und die Krätsche macht. Auch könnt Ihr 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 heruntergefahren werden muss.

Als nächstes widmen wir uns den Szenarien, indem eine Node abgeraucht ist, Ihr aber Eure Seeds, und SCB Backups regelmässig gesichert habt.

On Chain Guthaben wiederherstellen

Dies ist der einfachste und unproblematischste Schritt auf allen 3 System. Um Eure 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.

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 wiederherstellen. Um Euer Onchain guthaben wieder herzustellen, müsst Ihr Ihr eure Seedphrase eingeben, die Ihr beim erstellen einer Lightning Wallet aufgeschrieben habt.

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 Walle, eine reine Onchain Wallet, 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. Im schlimmsten Fall, tut Ihr die Eingabe, und überweisst die Coins auf eine neu erstellte Softwarewallet zum Beispiel mit der Sparrow Wallet, und erstellt Euch auf dem BTCPay Server danach ein frische, und überweisst die Coins an die frisch erstellte Wallet.

LND Wallet wiederherstellen

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.

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 hat der Benutzer 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

BitcoinCore Onchain Wallet

Habt Ihr keine Kanäle, könnt Ihr den Raspiblitz einfach neu aufsetzen und das Image neu auf die SD Kartenflashen. Bedenkt dabei immer das neuste Image zu benutzen. Sinnvoll ist es auch ein SD Karte aus den höheren Preisklassen auszuwählen, da SD Karten bei regelmässiger Belastung nicht besonders lang halten.

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 Eure alten LND Azeed eingeben. Folgt einfach den Anweisungen.

Offchain Guthaben oder Lightning Kanäle sichern

Kommen wir zur Static Channel Backup Datei als Rettungsanker des gesammten Lightning Guthabens. 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 neuen LND-Knoten 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 aktuellen Saldos oder der Transaktionshistorie. 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
while true; do
    inotifywait /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup
    cp /var/lib/docker/volumes/generated_lnd_bitcoin_datadir/_data/data/chain/bitcoin/mainnet/channel.backup /backuppfad/channel.backup
done

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

Macht die Date ausführbar mit:

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

als Service hinzufügen

Erstellt eine neue Service Datei mit sudo emacs /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 den Service 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 /pfad/zur/datei/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.

Raspiblitz SCB Datei sichern

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 der 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 die fstab mit ein, damit der Stick automatisch 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 fstab unter /mnt/backup gemounted werden. Benutzt dabzu am besten die UUID.

Manuelle Konfiguration Auto-SCB Backup

Für das Autobackup des SCB via USB 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 des Sicks anzeigen lassen (Achtung! Das ist mein Stick - sieht bei Euch anders aus)

Status des Services nochmals abrufen:

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+W dann Y und ENTER

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.

Backups via Netzwerkanbindungen direkt zb 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

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 vorraussetzt, 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ässigen Auto channel.backup USB-Stick kommen, oder Ihr habt Ihr aus Eurem Netzwerkspeicher bereits zurück auf das System transferiert.

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.

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.

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 erstelle 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.

SCB Wiederherstellung BTCPay Docker

Um Kanäle wiederherzustellen müssen wir zuerst die alte urpsrüngliche LND Onchainwallet wiederherstellen, und den Wiederherstellungsbefehl erfolgreichmanuel ausführen. Wie Ihr die LND Wallet wiederherstellt, habt Ihr bereits hier erfahren. Springt nochmals zurück, falls Ihr das 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

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 wieder hergestellt 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 Transaktionen im Netzwerk

Ö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 einer aktuelle Durchschnittlichen Feerate von ca 50-150 sats/vbyte kann es sehr 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 lassen sich auch auf dem Blitz installieren, von einigen Usern habe ich jedoch erfahren, dass dies nicht immer fehlerfrei funktioniert.

Gebt den Befehl chantools in die Konsole ein, bekommt Ihr eine Befehlsübersicht, habt Ihr eine funktionierende Installation. Wenn nicht, kompilieren wir uns chantools auf einem anderen Linux Rechner, oder einer virtuellen Maschine Eurer Wahl.

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.

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 eine PSBT für Euren Server, auf dem 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 abzugeben, 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 Euer 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 deine 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 nicht mehr online ist.

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 musst du jetzt warten, bis die dir 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ühre 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. Öffne die resultierende JSON-Datei des letzten Befehls (./results/forceclose-yyyy-mm-dd.json) und suche jeden 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. Verwende den folgenden Befehl, um alle Kanalgelder an eine Adresse deiner 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, hab 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.

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

Damit haben wir es nun auch geschafft, wenn Ihr bis jetzt durchgehalten habt, meisterhaft! 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 Seiten zusammen suchen müssen. Im Anhang findet Ihr nochmals alle Quellen, Links und Github Seiten, aus denen die Informationen stammen

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!