ich habe mich bis jetzt geweigert eine Lightning Node aufzusetzen, würde das insgesammt aber gerne tun.
Was mich bis jetzt davon abgehalten hat ist die Unsicherheit der eigenen Coins bei einem Ausfall.
Im Bitcoin Netzwerk ist dies kein Problem, die eigenen Transaktionen werden von Millionen anderen Nodes gespeichert. Wenn die eigene Node mal ausfällt, auch mal länger für einen Tag oder eine Woche, dann syncronisiert man die letzten Blöcke und gut ist.
Bei Lightning stehen die Werte im eigenen Channel bei einem Ausfall auf der Kippe. Man muss im Ausfall-Fall auf einer anderen Node/Person/Entität vertrauen, dass sie keinen Unsinn mit den Channels macht.
Natürlich kann man das Vertrauen weiter auslagern indem man sich einen Watchtower kauft, der im Notfall die Channels auch überwacht. Aber dann muss man wieder einer dritten Partei vertrauen. Und den Watchtower auf der gleichen Node laufen zu lassen macht auch nur begrenzt Sinn. Fällt die Node aus, dann ist auch der Watchtower weg.
Man könnte einen eigenen Whatchtower irgendwo in einer Cloud betreiben, oder zumindest irgendwo an einem anderen Standort (Freunde, Eltern, Uni/Betrieb usw.) was die Ausfallsicherheit erhöhen würde. Allerdings sichert das nur die eigenen Werte in den Channels, die Channels würden bei einem Ausfall trotsdem down gehen auch wenn ein Watchtower den Channelpartner weiter überwacht.
Deswegen die Frage: Gibt es redundante Lightning Nodes? Also dass man zwei oder mehr physische Computer hat, auf denen die gleiche Lighningnode läuft, sodass eine (oder n-1) der im Verbund aggierenden Nodes ausfallen kann ohne dass der Service, also all die Lighningchannels der Node unerreichbar werden?
Soweit ich das vor einem halbem Jahr recherchiert habe gab es noch keine redundante Nodes. Hat sich das inzwischen geändert? Oder hab ich nur nicht die richtigen Stellen im Internet gefunden?
Redundanz gibt es ja in verschiedenen Ausprägungen. Wenn es um die Hochverfügbarkeit der Node geht wird es technisch schon ziemlich anspruchsvoll. Die Frage ist ja ob man dafür viel Geld ausgeben will oder ob es ok ist das die Node bei einem defekt mal 1-2 Tage down ist und man auf neuer Hardware weitermacht.
Letztendlich geht’s bei LND ja um die Channel.db die man in aktuellster Form braucht um die defekte Node auf neuer Hardware weiterbetreiben zu können. Entweder schreibt man die Daten live weg oder sorgt mit Redundanz des Speichers dafür das zumindest ein Hardwaredefekt nicht zu Inkonsistenz der Daten führt.
Wie du es beschreibst, willst du die Nodes quasi clustern. Das wäre auch denkbar wenn sich die Nodes einen Speicher teilen (SAN, anderweitiger Share). Die Failovermechanismen müssen aber zu 100% sicherstellen das niemals beide Nodes gleichzeitig aktiv werden. Das wäre tödlich für die Node.
Das würde in dem Setup keinen Sinn ergeben. Wäre es 2 identische Nodes hättest du nach kürzester Zeit den maximalen Schaden durch PenalyCloses da Transaktionen die CloneA verarbeitet auf CloneB nicht bekannt sind. Ein gemeinsamer Share, so das beide Nodes sich eine channel.db teilen würde vermutlich instant zu einer korrupten DB führen.
Was eher funktionieren kann wäre (sowas können LoadBalancer auch) ein Active/Standby Setup. Der Share schwenkt dann zu einer identisch konfigurierten BackupNode die dann aktiv wird.
Es gibt kein Load-Balancing-System für Lightning, die Frage stellt sich nicht.
Für maximale Verfügbarkeit, kannst du natürlich 2 oder mehr getrennte Nodes betreiben „DasPie1“, „DasPie2“ usw. die aber unabhängig voneinander agieren.
Aber dein Ziel war ja nicht Verfügbarkeit sondern Sicherheit deiner Sats, da ist LoadBalancing, wie @kieselbert erklärt hat eine schlechte Idee.
Das Argument find ich Komisch: Wenn meine Node ausfällt ist die Sicherheit meiner Sats definitiv gefärdet. Und das kann entweder: Hardwarefehler, Softwarefehler oder Internetausfall einschließen. Redundanz ist daher meiner Meinung nach wichtig.
Es ist vielleicht dennoch gut wenn wir die Zielstellung im Auge behalten. Explizites Clustering von Nodes gibt es derzeit nicht, normale Failover-Mechanismen müsste man ganz genau verstehen und anpassen. Es ist mit Sicherheit günstiger einen Watchdog auf einem getrennten System zu betreiben um die Sats in den Channels abzusichern (wenn die eigene Node defekt ist). Ansonsten sollte man natürlich über das SCB verfügen, falls die Reparatur der Node fehlschlägt.
Wenn man frisch mit einer Node startet kann man z.B. postgres als Datenbank konfigurieren. Diese Daten kann man live zu einer zweiten Node senden auf der LND nicht läuft. Die wäre dann quasi Standby bereit für den Betrieb wenn die primäre Node ausfällt. Aber solche Setups gibts nicht fertig, sondern erfordert das man sich sehr gut auskennt.
Um Sats aus Channels wiederherzustellen, speicherst du die SCB-Datei regelmäßig auf einem externen Medium.
Sollte es im Falle einer Downtime zu einem Remote Force Close mit veränderten Channel-Balance-Ständen kommen, würde ein Watchtower auf einem schlanken VPS aufgesetzt für wenig Fiat im Monat ausreichen.
Ich hatte schon Fälle wo das Internet mehrere Tage im Haus nicht funktioniert hat und auf einen Ersatz Modem musste ich schon mal 1 Woche warten. So was ist selten aber es passiert.
Eine Möglichkeit um das zu überbrücken wäre vielleicht ein Router das mit einer SIM Karte funktioniert.
Oder man benutzt Starlink und zahlt einmalig ca. 500€ und monatlich 80€ für eine 50-200 Mbit/s Leitung. Gar nicht übertrieben …
Naja, was ist, wenn es eine Transaktion gab und bevor diese gesichert ist brennt die Node-Festplatte durch?
Ja ein Whatchtower kann hier helfen Schadensbegrenzung zu machen, aber es wäre doch nützlicher gleich eine andere Node zu haben, die redundant einspringt.
Allerdings bin ich mir noch nicht ganz sicher ob das Konzeptionell überhaupt möglich ist. Immerhin ist Lingtning ein Peer to Peer austausch. Also wenn mein Gegenüber eine Nachricht sendet, dann muss es immer erstmal irgendwo eine einzelne Instanz geben, die die Nachricht aufnimmt und gegebenenfalls verteilt. Diese Instanz kann versagen und somit den Channel gefärden.
Einzige Lösung dazu, die mir einfällt wäre, wenn man schon dem Channelpartner sagen kann, dass er Transaktionen nicht nur an eine Node senden soll sondern an x eingestellte Nodes. Das würde bedeuten, dass man zusammen mit seinem Channelpartner einen Cluster aufmacht der sich automatisch synchronisieren muss unter der Nebenbedingung, dass der Cluster in zwei feindliche Lager sich spalten kann.
What?
Wenn du dir so viele Sorgen machst, dann würde ich abraten, eine LN Node zu betreiben.
Ich betreibe seit über einem Jahr eine Node mit
Raid1-Verbund von zwei SSDs für die Daten/Datenbanken
USV gegen Stromausfälle
SCB remote gesichert, um die Funds wiederherstellen zu können
und das reicht. Wenn die Node down geht, dann geht sie down. Wenn ein HTLC in das Timeout läuft, force closed die Node sowieso den Channel und holt das Payment on-chain zurück. Dass es eine Transaktion geben soll, die nicht gesichert ist, … schlägt eher der Blitz ein.
Ich habe gelesen auch ein CDN fiel schon mal für mindestens 1 Std. aus. Es gibt also keine absolute Garantie. Bei den ganzen Redundanz Systemen geht es eigentlich nur darum die Wahrscheinlichkeit für Ausfälle zu minieren.
Und man muss schauen was man sich erlauben darf und was nicht. Systeme wo im Minutentakt massenweise Zugriffe stattfinden sind schon 15 Minuten Ausfallzeit sehr unschön, während das bei einem durchschnittlichen Lightning Node nicht so dramatisch wäre.
So was wie ein Load Balancer kann versagen aber es wäre doch schon ausreichend wenn bei einem Ausfall du automatisch benachrichtigt wirst und dann greifst du so bald wie möglich auf dein Ersatz Gerät und wechselst es bzw. behebst den Fehler.
Da muss ja schon sehr viel über den Node geroutet werden dass so kurze Ausfallzeiten schmerzen.
Ja, vielleicht denke ich einfach in zu großen Maßstäben. Wie gesagt noch habe ich meine Node nicht um Lightning erweitert weil ich diese ausfallbedenken hatte. Dass heisst aber auch, dass ich noch keine Erfahrung mit lightning habe und mir vielleicht unbegründet zu viele sorgen um diese Probleme mache.
Es gibt USV Geräte schon ab 50€. Sind die günstigeren Modelle gut genug damit man eine Node einfach sicher herunterfahren kann?
Ich experimentiere aktuell mit Lightning herum und habe nur ein paar Kanäle mit winziger Liquidität.
Zum öffnen eines Kanals brauchst du normalerweise mindestens 20k Sats. Du kannst also erstmal mit unbedeutenden Summen erste Erfahrungen sammeln. Bevor du Kanäle mit vernünftiger Liquidität öffnest.
Kann ich nicht sagen. Je nach Strombedarf und Einsatzzweck gibt es verschiedenste Varianten. Hauptsache ist, dass sie über USB mit der Node kommunizieren kann und im Backupfall einen graceful shutdown der Prozesse initiiert, sodass kein Datenverlust eintritt.
Wie sichere ich mich denn am besten gegen einen Ausfall der Node ab? Also falls der raspberry oder die festplatte durchbrennt. Wie komme ich dann möglichst schnell wieder online um innerhalb des time lock zeitraums meine funds zu sichern?
Ist es sinnvoll einen 2ten raspberry als reserve zu hause zu haben falls der aktive kaputt geht? Evtl dann auch eine 2te Festplatte auf der man bereits die Bitcoin Blockchain heruntergeladen hat (sodass man sich bei einem möglichen Ausfall die zeit für den download spart)? Oder gibt es andere bessere/schnellere Lösungen?
Also zunächst mal teile ich den Restore in 2 Arten ein:
Node geht kaputt, Hauptsache ich bekomm meine Sats wieder
Node geht kaputt, ich will so schnell wie möglich wieder online gehen und meine Channels sollen auch noch existieren.
zu 1.
Da reicht es wenn du den Seed zu deiner Node-Wallet hast und ein aktuelles SCB (Static Channel Backup). Aktuell heißt seit dem letzten geöffneten Channel, das reicht.
Damit kannst du mit einer neuen Node die Channels schließen und hast die Sats wieder in deiner Wallet. Die Teile (HDD & Raspberry bereits als Ersatz zu haben ist natürlich hilfreich.)
Wenn du befürchtest in der Lockzeit das neue Setup nicht an den Start zu bekommen wäre es wichtig deine Node bei einen Watchdog anzumelden, der passt dann auf das dir keiner Funds klaut wärend du deine neue Node aufbaust.
zu 2.
Hier wird es richtig interessant, weil du dazu die channel.db im absolut aktuellen Zustand besitzen musst. Das erfordert dann ein deutlich anspruchsvolleres Setup. Bei mir liegen die Daten deshalb auf einem Raid, was aber auch kein 100% Schutz ist, die DB kann auch wegen RAM-Problemen oder sonstigem korrupt werden. Es gibt Leute die schreiben sich alles nochmal parallel in eine zweite Datenbank auf einem anderen System.
Falls es von Interesse ist wie ich das derzeit handhabe:
2x Lightning (LND) läuft virtuell in LXC Containern
BitcoinNode läuft separat virtuell in doppelter Ausführung (1x Full, 1x Pruned), dadurch kann ich Lightning auf ne alternative Node schwenken wenn mal eine Blockchain kaputt geht (hatte ich schon, ist nicht schön)
Die (n-1)-Ausfallsicherheit ist ein ziemlicher Overkill für Lightning. Die Vorredner haben schon die Schwierigkeiten bei der Implementierung angesprochen. Ich denke aber, dass es für Lightning auch garnicht nötig ist. Das Lightning-Protokoll ist ziemlich resilient gegenüber kurzzeitigen Ausfällen einer Node. Wenn man es mit einer Standby- oder Failover-Lösung schafft, die Node wieder hochzufahren, bevor irgendein Timelock in den Kanälen abläuft, besteht kein Verlustrisiko, auch ohne Watchtower.
Das einzige echte Risiko, über das man sich Gedanken machen muss, ist, dass die Datenbank korrumpiert wird und man die Node nicht mit dem letzten Zustand sicher wiederherstellen kann. Dann besteht in der Tat ein hohes Verlustrisiko.
Wenn man dieses Problem angemessen adressiert hat, ist es völlig ausreichend, einen Standby-Server zu haben, der bei Ausfall der Hauptnode die Funktion übernimmt.
.