Der Raspberry Pi ist als kleiner Heimserver für eine Lightning Node sehr beliebt, nicht zuletzt wegen der geringen Anschaffungs- und Betriebskosten. Wenn man nur experimentiert oder mit kleinen Beträgen arbeitet, deren Verlust notfalls verkraftbar ist, ist das auch vollkommen ausreichend. Allerdings erfüllt er nicht die Anforderungen an kritische Systeme, deren Versagen substantielle Kosten verursachen kann. Hier mal einer der wenigen guten Artikel mit solchen Erwägungen:
Wesentliche Anforderungen wie ein ECC-RAM, RAID-1, USV sind bei vielen RPi-basierten DIY-Anleitungen oder auch (halb-)kommerziellen Lightning Nodes nicht enthalten oder technisch garnicht möglich (im Fall ECC-RAM).
Daraus ergeben sich die Fragen:
Ist es nicht gefährlich, den RPi als Lightning Node Hardware für mehr als nur Experimentierzwecke zu empfehlen oder gar zu vermarkten? Sind den Anwendern die Risiken bewusst?
Ergeben sich hieraus Gefahren für das Lightning-Netzwerk als Ganzes?
Welche Hardware wäre stattdessen für (ggf. ambitioniertere) Heimanwender zu empfehlen? Der o.g. Artikel spricht eine Empfehlung aus, aber vielleicht gibt es andere Vorschläge oder Erfahrungen?
Ich persönlich warte auch mit lightning bis ich eine Node redundant betreiben kann. Dass zwei oder mehr Nodes gleichzeitig ausfallen senkt die Risiken wieder, aber solche Implementierungen hab ich bis jetzt nicht gefunden.
Ja es gibt Whatchtower die die Sicherheit wieder erhöhen. Richtige Redundanz ist das aber nicht.
Guter Punkt. Aber was genau meinst du mit richtiger Redundanz? Spätestens die Kommunikation mit den Peers kann ja nur von einem Gerät aus erfolgen. Was natürlich unverzichtbar (aber jetzt schon möglich) ist, ist die Datenbank mit dem Zustand der Node im Betrieb laufend auf einem zweiten Gerät zu backupen, das in Bereitschaft gehalten wird, um die Funktion des Ersten jederzeit übernehmen zu können. Dieses Konzept geht an Sicherheit über Watchtower weit hinaus. Wovor es aber nicht schützen kann, sind Datenkorruption durch Stromausfälle (dafür braucht man die USV) oder Bit Flips (dafür ECC RAM).
Redundanz ist weit mehr als einfach nur die Datenbestände synchron zu halten. Redundanz ist wie eine Art Cluster an dem die Anfragen gestellt werden und wie bei Bitcoin kann aus diesem Cluster jederzeit ein Computer ausfallen ohne dass jegliche Funktionalität gestört ist. In einer N-Fachen Redundanz können also N Computer gleichzeitig ausfallen ohne dass der jeweilige Service unterbrochen wird und beliebig Computer wieder hinzugeschaltet werden.
Damit wäre echte Redundanz natürlich, dass man einen Computer bei sich hat, einen bei seinen Eltern oder in irgendeinem Rechenzentrum usw. Kleinere Stromausfälle wären somit nicht mehr relevant. Bit-Flips auch nicht da sie innerhalb des Clusters bereinigt werden (Sie müssen sich ja auch bei einer neuen Node im Cluster auch wieder synchronisieren).
Das sind zwar programmiertechnisch sehr hohe Anforderungen, aber durchaus möglich und implementierbar. Gerade große Firmen wie Google, Facebook, Twitter aber auch jede Bank geben eine Menge Geld aus damit ihre Services redundant sind, also dass es zu keiner Zeit eine Störung vorhanden sein soll egal welcher Art. Und Da Computer immer irgendwie kaputt gehen ist die Industrie dazu übergegangen Hardwareunabhängige Programme zu schreiben, also z.B. Funktionen in einem Cluster auszuführen. Egal wann ein Computer des Clusters dann mal die Kontakte hochstreckt, die Funktion wird dann eben sofort woanders ausgeführt ohne dass der Kunde etwas davon mitbekommt. Genauso können auch z.B. Updates eingespielt werden oder Computer mal neugestartet werden ohne dass es eine Downtime des Services geben muss.
Okay, das wäre aber softwaretechnisch schon sehr aufwändig für Lightning, was ohnehin schon ein recht komplexes System ist. Wenn es möglich wäre, wäre das natürlich das Optimum. Bis dahin müssen wir uns wohl doch um die optimale Hardware Gedanken machen.
Welche Verluste drohen bei Datenkorruption eigentlich genau? Es sollte doch möglich sein mit einem neuen Gerät auf den Wallet zuzugreifen und einen force close der Kanäle durchzuführen? Dann wäre der Schaden auf die finanziellen Verluste während der Ausfallzeit begrenzt?
Stelle ich mir komisch vor, wenn jemand Kanäle im Wert von tausenden von Euros aufmacht aber das ganze auf einem Raspi laufen lässt.
Ich denke nicht. Laut mempool.space laufen fast alle Nodes bei großen Cloud Anbietern wie Google und Amazon. Schlimm wäre es also wenn es massive Ausfälle bei diesen Anbietern gäbe. Warum auch immer es trotz Redunanz zu solchen Ausfällen kommt. Kann immer was geben. Technische Probleme oder Sicherheitsprobleme könnten vorrübergehend große Ausfälle verursachen.
Am Ende muss jeder für sich abwägen, ob sich der Aufwand für eine höhere Ausfallsicherheit bzw. Datenintegrität lohnt. Meiner Meinung nach ist ein Raspberry Pi (zB mit Raspiblitz) - 8 GB RAM, vernünftige SSD und Micro-SD Karte vorausgesetzt - völlig in Ordnung, um eine private Node (keine Routing-Node) mit überschaubaren Funds in den Kanälen (on-Chain Funds sind sowieso nicht in Gefahr) zu betreiben. Auch gute Micro-SD Karten sollte man außerdem nicht zu lange benutzen.
Das SCB (static channel backup) kann man automatisiert an einen anderen Ort kopieren lassen (NAS und/oder Cloud, natürlich verschlüsselt). Das senkt schon mal deutlich die Wahrscheinlichkeit, dass man im Fall von Datenverlust (SSD defekt oder Channel Datenbank korrupt) seine Funds verliert. Wenn man Zombie-Kanäle vermeidet (also erkennt und zeitnah mit noch funktionierender Node schließt), kann schon fast nichts mehr passieren (ein SCB nützt einem nichts, wenn Funds in Zombie-Kanälen stecken und der entsprechende Channel-Partner keinen Force-Close durchführt).
Stromausfälle sind je nach Standort sehr unwahrscheinlich, können mit einer USV (die man natürlich auch für einen Raspberry Pi installieren kann) aber problemlos entschärft werden. Man sollte sich nur darüber im Klaren sein, dass eine USV dauerhaft Energie braucht (Ladeelektronik, Verluste durch AC<->DC Wandlung) → der Gesamtenergieverbrauch zum Betrieb der Node wird sich ca. verdoppeln. Ich persönlich verzichte auf eine USV, da ich das Risiko für äußerst gering halte, dass der Stromausfall in genau dem Moment kommt, wo ich einen neuen Channel geöffnet habe (oder einen Channel-Parameter geändert habe), aber die neue SCB noch nicht in die Cloud hochgeladen wurde.
Der Strom kann auch abrupt ausfallen wenn die Sicherung raus fliegt. Ich habe das mit meinem PC Netzteil schon häufig verursacht
Immer wenn ich den Hauptschalter beim Netzteil betätige muss ich damit rechnen dass die Sicherung raus fliegt und es braucht dann ein paar Versuche bis es gelingt. Das passiert bei mir mit verschiedenen Netzteilen und Computern. Ich vermute mal die Sicherungen sind einfach zu alt und empfindlich.
Ja, wenn die Elektrik zuhause in so einem Zustand ist (oder das PC-Netzteil defekt ist und beim Einschaltvorgang mehr zieht als die Sicherung verträgt), weiß man das ja und muss eben entsprechend Maßnahmen ergreifen Daher sage ich ja, das ganze muss man individuell abwägen. Zur Risikobewertung sollte man sich Aspekte angucken: Eintrittswahrscheinlichkeit und Schadenschwere. Was Stromausfall angeht habe ich persönlich seit 6 Jahren keine einzige Sekunde Stromausfall gehabt, die Eintrittswahrscheinlichkeit bewerte ich daher als sehr gering. Die Schadenschwere ebenfalls (SCB immer sofort aktuell in der Cloud, keine Zombie-Kanäle).
Einen force close kann man nur durchführen, wenn man den letzten Zustand des Kanals besitzt. Man braucht also mindestens immer ein zuverlässig aktuelles Backup der Node-Datenbank. Sind diese Daten verloren, geht es nicht. Dann kann man nur noch darauf hoffen, dass der Kanal-Peer den Kanal schließt, was man aber nicht erzwingen kann. Außerdem droht natürlich bei Datenkorruption im RAM, zb einem Bit Flip, dass man Coins ausversehen an den falschen Empfänger sendet oder die Node sonst irgendwie in einen undefinierten Zustand gerät, aus dem man sie nicht wiederherstellen kann.
Das ist ja schonmal schlecht. Cloud-Anbieter kommen eigentlich nicht in Frage, wenn man die Selbstverwahrung ernst nimmt. Idealerweise sollten Node-Betreiber die Hardware, die ihre Schlüssel verwaltet, auch physisch besitzen. Ansonsten teile ich tendenziell deine Einschätzung.
Das ist auf jeden Fall eine sinnvolle Maßnahme, allerdings ist man auch mit SCB auf die Kooperation des Kanal-Peers angewiesen. Wenn der entweder nicht kooperiert oder schlicht auch ausfällt sind die Sats im Kanal verloren.
Zum Thema USV: Ja, die verbraucht natürlich zusätzlich Strom, bei geeigneten Modellen aber nur wenig (Größenordnung 5W). Zusätzlich kann man den Router daran anschließen, der ja auch weiterlaufen sollte und ebenfalls Strom verbraucht (und ggf. natürlich weitere schützenswerte Geräte). Insofern kann man eigentlich nicht behaupten, dass sich der Stromverbrauch der Gesamtkonfiguration verdoppelt. Nach meiner Einschätzung ist die USV eine absolute Mindestmaßnahme.
Deshalb ist es grundsätzlich empfehlenswert Zombie-Kanäle zu erkennen und zu schließen. Solange die Nodes der Channel-Partner noch laufen, wird die Verwendung von SCBs (das entspricht quasi einer Aufforderung an diese Nodes einen Force-Close durchzuführen) mit hoher Wahrscheinlichkeit funktionieren, da kein manuelles Zutun der Node-Betreiber notwendig ist. Die Node führt den Force-Close automatisch durch, aber genau: dafür muss sie funktionieren.
Doch, das kommt schon hin bei einem Raspberry Pi, denn der zieht sich auch in der Größenordnung 5-10 W Energie rein, so wie eine USV eben auch. Dass man die USV, wenn sie erstmal angeschafft wurde und läuft, auch noch für Router und evtl. weitere Geräte verwenden kann, stimmt. Aber wenn man sie für die Lightning-Node anschafft, ist der Vergleich:
Nur Pi (5-10 W)
Pi + USV (10-20 W)
Den Router hat man ja sowieso, egal, ob man eine Lightning-Node betreibt oder nicht, insofern hat sein Energieverbrauch in der Rechnung nichts zu suchen.
Alles richtig, nur eine Garantie gibt es eben nicht. Also ist eine redundante Speicherung der Datenbank den SCBs schon überlegen, auch wenn SCBs natürlich besser sind als garnichts.
Der Vergleich hinkt. Ohne den Router nützt dir dein Pi überhaupt nichts als Node, also musst du den Router beim Stromverbrauch deiner Node-Konfiguration fairerweise schon mitberücksichtigen. Dann ist es keine Verdopplung mehr.
Theoretisch ja. Aber ein falscher Umgang mit der Channel Datenbank kann zum Verlust der Funds führen (wenn für die Kanal-Schließung versehentlich ein nicht-aktueller Stand veröffentlicht wird [und das ist in Grenzfällen gar nicht so leicht zu erkennen] → die Partner-Node bzw. ein Watchtower wird dann die Penalty-TX broadcasten). Du handelst dir (je nach Know-How) also ein anderes Risiko ein.
Ich bin der Meinung, dass die SCBs alleine schon sehr viel Sicherheit bringen, denn es muss deine und die Partner-Node relativ zeitgleich (unwiederbringlich) abrauchen (oder die Partner-Node von vornherein boshaft unterwegs gewesen sein, also mit abgewandelter Lightning-Implementierung, die die Aufforderung für einen Force-Close ignoriert; aus spieltheoretischer Sicht ist das allerdings unwahrscheinlich, da man nur dem Gegenüber schaden kann ohne eigenen Vorteil, denn eine Veröffentlichung eines alten Stands des Channels würde durch einen Watchtower weiterhin entsprechend bestraft und man riskiert als Betrüger dann eigene Funds).
Wer kauft denn den Router nur, weil er ne Lightning-Node aufsetzt? Der Router läuft in 99,9% der Fälle sowieso schon und hat daher mit der Sache nichts zu tun.
Man muss eben wissen, dass es nicht ausreicht, von Zeit zu Zeit zu backupen, sondern der Backup immer auf aktuellem Stand sein muss.
Deshalb entweder RAID-1-Dateisystem oder automatisches Backup nach jeder Transaktion wie es beispielsweise bei Core Lightning möglich ist.
Ansonsten: Das größte Risiko bei den SCBs ist wohl wirklich, dass der Partner ebenfalls zu einem ähnlichen Zeitpunkt crasht ist und somit niemand mehr den Kanal schließen kann.
So kann man’s natürlich auch sehen, das ist aber ein ähnliches Argument, wie dass die USV ebenfalls anders nutzbar ist. Ist aber auch eigentlich eine sinnlose Debatte, viel mehr als darum, ob es nun eine Verdopplung ist oder nicht, kommt es ja auf den absoluten Mehrverbrauch an. 5W sind ca. 3,6 kWh im Monat, was selbst bei den astronomischen deutschen Strompreisen also ca. 1-2 € / Monat kostet. Kann sich dann jeder selbst überlegen, ob ihm das für die erhöhte Ausfallsicherheit zu teuer ist…
In Grenzfällen ist es wie gesagt gar nicht so leicht zu erkennen, dass das Channel Datenbank Backup nicht aktuell ist. Aber wie auch schon für die anderen Fälle beschrieben, ist die Wahrscheinlichkeit gering, dass sowas passiert. Wer nicht viele Zahlungen macht und keine Routing-Node betreibt (mit einem Raspi eh nicht empfehlenswert), dürfte kein nennenswertes Risiko haben, dass das automatische Channel Datenbank Backup nicht mehr klappt, die letzte Zustandsänderung im Kanal aber noch durchging. Aber im Gegensatz zu den SCBs ist die (ungeprüfte) Verwendung von Channel Datenbank Backups eben nicht gänzlich ungefährlich - das sollte einem bewusst sein.
Zur USV:
Da hast du Recht. Wer der Meinung ist, dass es einen Mehrwert bietet, wenn auch der Router über eine USV abgesichert ist und dadurch das Heimnetzwerk und evtl. (je nach Art des Stromausfalls) das Internet durch Akku-Geräte (Handy, Tablet, Laptop) noch nutzbar ist, der kann das mit in die Überlegung einpreisen.
Da ich persönlich wie gesagt seit vielen Jahren keinen einzigen Stromausfall erlebt habe, sind es mir die ~18 bis 35 € pro Jahr + Wartungskosten (Akku) nicht wert. Mit ein bisschen Glück ist meine channel.db trotz hartem powerdown des Pi nicht korrupt - im schlimmsten Fall muss ich meine paar Kanäle force-closen und neue eröffnen. Die Gebühren dafür sind (aktuell noch) deutlich unter ~18 bis 35 €.
Das heißt also wenn sich die Balance eines Kanals nach dem letzten SCB Backup ändert und direkt daraufhin es zu Datenkorruption kommt, kann man keinen force close des Kanals durchführen weil mein letzter SCB Backup nicht den letzten Stand des Kanals wiedergibt?
Was aber eigentlich früher oder später passieren dürfte, weil der Kanal ja tot ist und das wird der Gegenseite irgendwann auffallen. Man muss also unter Umständen nur sehr lange auf seine Sats warten aber sie gehen nicht verloren?
Bei einem Stromausfall im Haus wird ein aktiver Router unter Umständen nichts bringen. Wir haben ein Kabelanschluss und dafür gibt es einen Verteiler oder so was im Haus der alle Wohnungen versorgt. Wenn der kein Strom hat oder kaputt geht, gibt es über den Kabelanschluss keinen Internet.
Um das zu überbrücken bräuchte ich theoretisch einen alternativen Internetanschluss. Mobilfunk oder Starlink
Nein, bzw. hier muss man mit den Formulierungen wirklich kleinlich sein. Das SCB (static channel backup) ist eben wie der Name schon sagt statisch. Es muss nicht nach jeder Zahlung aktualisiert werden, sondern nur, wenn die Konfiguration des Kanals (Gebühreneinstellung etc.) geändert wird. Und natürlich braucht man ein neues SCB, wenn man einen neuen Kanal öffnet.
Die Verwendung eines SCB kommt technisch aber folgendem Ablauf gleich: Die Kanal-Konfiguration wird eingelesen und dann werden alle Channel-Partner darum gebeten, einen Force-Close durchzuführen. Deshalb ist es auch erforderlich, dass die anderen Nodes noch laufen.
Man selbst (deine Node) kann nur dann einen Force-Close durchführen, wenn sie noch läuft und eine funktionierende Lightning Channel Datenbank mit dem neuesten Stand (hier ist jede einzelne Zahlung relevant!) hat. Hierzu muss die Partner-Node nicht online sein (sie hat Zeit dem Force-Close mit der entsprechenden Guthabenverteilung zu widersprechen, tut sie das nicht, wird es on-chain so gesettelt wie du es angestoßen hast).
Daher sage ich ja, das ganze muss man individuell abwägen. Zur Risikobewertung sollte man sich Aspekte angucken: Eintrittswahrscheinlichkeit und Schadenschwere. Was Stromausfall angeht habe ich persönlich seit 6 Jahren keine einzige Sekunde Stromausfall gehabt, die Eintrittswahrscheinlichkeit bewerte ich daher als sehr gering. Die Schadenschwere ebenfalls (SCB immer sofort aktuell in der Cloud, keine Zombie-Kanäle).