Echtes Recovery Backup der Lightning Node unmöglich?

Fragen
1

Hallo zusammen!

Ich bin gerade stark am Zweifeln ob es Sinn macht, meine Lightning Node überhaupt weiter zu betreiben. Wie das zum Titel passt erkläre ich kurz,

Ich habe viel Zeit und Geld in den Aufbau meiner Routing Node gesteckt, aktuell über 100€ „im Minus“, also an Gebühren etc. bezahlt. Profit war so ca. 15€ (über ein Jahr alte node). Meine Node ist mittlerweile unter den Top 200 nodes und hat gute Kennzahlen (Betweennesss, Hopness,…).
Jetzt wollte ich mal eine Strategie zurechtlegen, wie ich ein wirklich funktionierendes desaster recovery scenario erstellen kann. Dabei stoße ich jedoch auf das Problem, dass es so etwas scheinbar nicht für den 0815 node Betreiber gibt.
Angenommen meine SSD raucht in 10min ab, was kann ich machen?
Einzige Lösung bis jetzt: Neu aufsetzen, channel backup einspielen, ewig warten bis alle channels geclosed sind und von vorne beginnen. Das ist eine Notfalllösung, aber keine recovery Strategie. Es kostet wieder unnötig Gebühren alle channels zu öffnen und nochmals teures rebalancing durchzuführen.

Falls ihr da etwas wisst, wie man ein tatsächliches recovery praktikabel umsetzen kann, bittte nur her damit. Habe auch schon versuch über Linux Dienste die relevanten Ordner alle 10min zu syncen, aber das ist auch nicht mehr als ein Krückstock.

Ich bin mittlerweile zu dem Schluss gekommen, dass es das Design von Lightning (für normale Benutzer) unmöglich macht, eine Node wirklich ausfallsicher zu betreiben. Wenn die SSD crasht, kannst du defacto von vorne anfangen und alle Gebühren nochmal zahlen.

Darum zweifle ich jetzt mittlerweile immer mehr, ob Lightning tatsächlich nicht einen oder sogar mehrere grundlegende Konstruktionsfehler/mängel hat. Der zweite Painpoint ist das ständige rebalancing, auch wenn es automatisch gemacht wird. Es kann doch nicht für ein durchdachtes Design sprechen, wenn ein signifikanter Teil des ganzes Traffics nur aus rebalancing Transaktionen besteht. Zumindest bei meiner Node sind etwa 1/3 der Transaktionen offensichtlich rebalances von anderen nodes. Wir schieben uns da gegenseitig die Gebühren zu und am meisten davon erhalten die wenigen zentralen nodes.

Ich habe fast 2BTC an Liquidität hineingesteckt und jetzt beschlossen, jedes rebalancing zu unterlassen. Mit über 40 channels war das Endergebnis, dass fast alle extrem inbalanced wurden und mittlerweile fast täglich ein channel zu mir geschlossen wird. Ich müsste also weiter fees bezahlen um neue zu öffnen. Ganz ehrlich, das kann es einfach nicht sein. Der ganze Aufwand für ein Verlustgeschäft und einen simplen second layer, der einfach nur BTC skalieren soll.

Punkte die mich zweifeln lassen:

  • Lightning ist immer noch Beta Software und es gibt bekannte und unbekannte Sicherheitsrisiken
  • Was darauf aufsetzt (layer 3) und BTC zum Durchbruch verhelfen soll ist immer noch Alpha Software. Das kann ein ganz übles Erwachen geben und ich habe keine Lust so viel Risiko zu tragen.
  • Das Konzept der channels und unveröffentlichten BTC Transaktionen fand ich am Anfang genial, als node Betreiber sehe ich aber die großen Nachteile. Ein paar Enthusiasten investeiren ihr Geld und ihre Zeit. Ich habe meinen Ethusiasmus verloren, wenn es nicht mal break even ist.
  • Keine vernünftige Backup Strategie. Wenn die Fullnode abraucht, dann habe ich nach ein, zwei Stunden eine voll funktionsfähige Fullnode wieder online. Simples database backup des ledgers. Bei Lightning fängt alles von vorne an.
  • Für Leute die Zahlungen professionell (Shops) über Lightning entgegennehmen wollen, ist es ohne tiefe Kenntnisse nicht möglich dies zu tun. Ich lese immer, dass man eben eine node mal richtig aufsetzen muss, auto rebalancing und alles läuft. Ja, so lange bis es einen hardware defekt gibt und man alles von vorne aufsetzen muss. Das machen die Leute vielleicht einmal mit, aber nicht öfter. Danach werden sie ein custody service verwenden und die Zentralisierung von Lightning ist schlimmer als beim größten Shitcoin.

Habt ihr konkrete Lösungen zu dem recovery Problem? Wenn das nicht wirklich praktikabel umgesetzt werden kann, dann werde ich meine node schließen. Die Situation will ich mir einfach sparen, jahrelang idealistisch Geld in etwas zu stecken, dass dann am Ende in Rauch aufgeht. Einfaches hodln wäre bis jetzt auch profitabler gewesen.

3 „Gefällt mir“
2

Das ist gefährlich, da bei einem Sat Unterschied zwischen Backup und Abrauchen bei Wiederaktivierung vermutlich die gesamte Kapazität an den Channelpartner geht, da deine Node versucht „zu bescheißen“.

Dafür gibt es RAID. Natürlich dann eher nicht an einem Pi. Aber man betreibt ja eigentlich auch keine „kommerzielle“ Riesennode über einen Pi, richtig? :wink:

Ja, ist so.

Das ist ja das Schöne: Musst du nicht.

Ist eigentlich kein Hexenwerk und nicht wirklich unterschiedlich zu anderen Applikationen in Rechenzentren. Natürlich sind hier mehr Investitionen notwendig, als nur einen Pi an die Fritzbox zu hängen. RAID, USV, redundantes Internet etc…

Ist es denn wirklich so schlimm, wenn Lightning zentralisierter ist und nicht jeder seine eigene Node betreibt?

Schließt sich zum Beispiel eine Einkaufsstraße mit allen Geschäften zusammen und betreibt eine zentrale Node für alle, ist es doch kein Problem. Dafür könnte der Betreiber eine kleine Entschädigung von den Nutzern erhalten und allen ist geholfen.

Oder ein Dorf betreibt eine gemeinsame Node.

Lightning ist „unsicherer“. Das ist aber gewollt, um die Geschwindigkeit zu erreichen.
Es mit einem Shitcoin zu vergleichen, ist unpassend. Bitcoin bleibt ja Bitcoin.

Gleiches Problem haben Miner. Nur die Hardware anschließen und „reich werden“ funktioniert leider nicht. Auch eine gute Lightningnode erfordert Arbeit und Investitionen. Vielleicht bringt die Zukunft Software, die das Leben von Nodebetreibern vereinfacht. Ich bin mir sogar sehr sicher.

Vielleicht setzt sich Lightning auch gar nicht durch und wir bekommen eine Alternative.

Bitcoin ist jung. Was ist dann das Lightning Netzwerk? Es ist gerade erst aus dem Ei geschlüpft. Nicht jeder muss ein Early Adopter sein. Du hast die Wahl! Wallet of Satoshi funktioniert großartig.

2 „Gefällt mir“
3

Danke für deine Antwort.

RAID habe ich mir auch schon überlegt, aber abgesehen davon, dass ich persönlich zwei Fälle kenne wo ein RAID 5 im Einsatz war und trotzdem alles neu aufgesetzt werden musste, wäre es eine weitere teure Investition. Diese wird sich niemals rechnen und wenn sich das ökonomisch beste Geld durchsetzt, dann wird es BTC nur schaffen, wenn Lightning sich stark verändert. Durch all diese Investionen habe ich am Ende weniger SATs als vorher. Ökonomisch sinnlos.

Ja! Wenn sich einige wenige zentralisierte nodes herauskristallisieren, dann können sie ihre fee-Politik beliebig gestalten und es kleineren Nodebetreibern unmöglich machen sinnvoll zu wirtschaften. Egal ob BTC darunter dezentral ist, wir hätten nichts gewonnen. Einzelne BTC Transaktionen werden teuer werden (ökonomisch sionnlos sie für einzelme Zahlungen zu verwenden) und Lightning wird von wenigen zentralen Entitäten kontrolliert. Wir hätten nichts gewonnen. Gar nichts.

Mir ist klar, dass diese Vergleiche schlecht ankommen. Es ist mir aber egal auf welchem Layer ich meine Bitcoin verliere. Bringt wenig, wenn die settlement Transaktion zum dem Betrüger dann dezentralisiert und sicher abläuft. Schön für ihn, meine BTC sind weg.

Ich würde aber lieber beim Thema bleiben, denn ich würde gerne das LNG Netzwerk unterstützen wie bisher, aber es ist momentan einfach eine Liebhaberei. Ein Hobby, das Geld kostet. Wenn man den großen Nodes das Feld überlässt, dann könnte die Revolution ihre eigenen Kinder fressen.

Falls noch jemand eine praktikable Methode verwendet (ohne teuere Hardware) um seine node zu sichern, bitte melden.

4

Zur Sicherung

Welche Software verwendest du? Core Lightning, LND, Eclair oder etwas anderes? Falls es Core Lightning ist, stehen wichtige Informationen und weitere nützliche Hinweise zur Sicherung hier:

Ähnliche Optionen werden sicher auch für die anderen Implementierungen existieren, mit denen ich mich aber nicht auskenne. Wichtig ist, wie @GBC schon geschrieben hat, dass die Datenbank kontinuierlich gebackupt wird, also jede Datenbanktransaktion synchron auf einem zweiten Datenträger repliziert wird, welcher sich am besten an einem anderen Standord befindet (über NFS o.ä.).

Zur Profitabilität

Das ist natürlich ein schwieriges Thema. Ich weiß nicht, wie du es bisher gemacht hast, aber vermutlich wird es ohne eine sehr ausgeklügelte Kombination aus automatisiertem Fee Management, Rebalancing und hoher Liquidität unmöglich sein, profitabel zu operieren. Die andere Option besteht natürlich darin, deine Node deutlich zu verkleinern und nur noch wenige kleinere Kanäle zu gut ausgewählten und zuverlässigen Partnern offen zu halten. Damit wirst du zwar nicht profitabel werden, aber deine absoluten Betriebskosten, den Arbeitsaufwand und das Verlustrisiko deutlich reduzieren und dann damit das Lightning-Netzwerk weiterhin als Hobby unterstützen. Auch viele untereinander gut vernetzte, kleinere Nodes können den größeren Konkurrenz machen.

5

Vielen Dank, das sieht interessant aus. Ich benutze umbrel, aber vielleicht lässt sich hier etwas machen.
Das hilft schon mal weiter! Danke!

1 „Gefällt mir“
6

Umbrel ist ja (u.a.) eine Art Paket-Management-System. Die zugrundeliegende Implementierung der „Lightning Node“ auf Umbrel ist LND. Vermutlich verwendest du die? In dem Fall wird dir der Link oben nicht so viel weiter helfen, da müsstest du die Datenbank-Backupoptionen für LND nachschlagen.

7

Danke für deine Mithilfe!
Ich bin jetzt zu dem Schluss gekommen, dass es wohl das klügste wäre, eine Hardware Raid Lösung zu verwenden. Das hat mich am meisten überzeugt.
Problem ist halt, dass man hier von Raspi etc. weit weg ist und die Investitionskosten nicht mehr so klein sind, wie gerne geglaubt. Eine Software Raid Lösung scheint mir unzuverlässiger, aber sicher besser als nichts.

8

Hardware-Raid ist definitiv eine gute Idee, um sich gegen Hardwaredefekte abzusichern. Es schützt allerdings auch nicht vor allen Risiken. Wenn sich die redundanten Festplatten am selben Standort befinden, besteht immernoch die Gefahr, dass diese durch einen Schadensfall gleichzeitig zerstört werden (Brand, Wasserschaden, umfallende Möbel, Kinder, Haustiere, Einbruch, usw…). Mein bevorzugtes Setting ist daher, einen synchronen Backup an einem zweiten Standort, z.B. in der Wohnung einer Vertrauensperson, zu führen. Hat den zusätzlichen Vorteil, dass man es auch mit billiger Hardware (z.B. zwei RPis) umsetzen kann. Nur so als Vorschlag…