Ich möchte meine LN-Channels und die OnChain BTC von einer Umbrelnode auf eine andere übertragen.
Kann ich auf der neuen Node die 24-Wörter eingeben und die Channels wiederherstellen und dabei die „alte“ Node weiterlaufen lassen?
kurze Antwort: Nein, auf keinen Fall.
Grund: nur eine Node verarbeitet die jeweilige Transaktion und die andere weis nix davon. Das heißt die Datenbanken laufen zwangsweise auseinander. Da es sich nach außen aber nur als eine Node zeigt, fängt mindestens eine von beiden an falsche channel states zu sehen bzw zu produzieren. Es wird zu force closes kommen und im schlimmsten Fall zu penalty Transaktionen bei denen du den kompletten Channelinhalt verlierst. Ist also ne ganz ganz schlechte Idee.
1 „Gefällt mir“
Hi Kieselbert,
vielen Dank für deine rasche Antwort! Ja, das hatte ich schon vermutet… Ich werde dann die „neue“ Node frisch aufsetzen (mit neuem Seed), die Channels neu aufmachen und die Funds rüberschicken…
1 „Gefällt mir“
Wenn es nur um einen Umzug handelt ist das schon möglich, aber dann solltest du immer wissen was du gerade tust.
Du kannst zb. Die erste Node vom Internet trennen, dann die komplette Datenbank auf die zweite node kopieren. Beide Nodes sollten dann den aktuellsten Datenstand haben und eine von beiden kannst du dann wieder produktiv nutzen. Du solltest aber nie beide gleichzeitig nutzen weil die jeweiligen Datenbanken dann nicht mehr gesynct sind, also unterschiedliche Datenbestände beinhalten können.
Was ich auch schade finde ist, dass es aktuell keine redundanz für lightning gibt. Also außer einem whatchtower zu vertrauen bleibt dir nichts weiter übrig als darauf zu vertrauen dass die Datenbank nie kaputt geht. Sowas wie ein lightning-cluster mit mehreren physischen nodes wäre gut.
Ein Watchtower greift nur ein, wenn jemand einen veralteten Zustand eines Lightning-Kanals veröffentlicht (also die gelockten on-chain BTC entsprechend dieses Zustands an die beiden Kanal-Partner freigeben will). Der Watchtower wird dann automatisiert eine penalty-transaction veröffentlichen, sodass die on-chain BTC freigegeben werden, aber der Kanal-Partner, der den veralteten Zustand veröffentlicht hat, gar nichts bekommt.
Ein vernünftiges Lightning-Node Setup beinhaltet grundsätzlich, dass das SCB (static channel backup) bei Bedarf* automatisch lokal und an einem 2. Ort (nicht auf dem gleichen Speichermedium, am besten auch nicht im selben Gebäude) gespeichert wird.
*Bei Bedarf heißt: Es wurde ein neuer Kanal geöffnet, ein vorhandener geschlossen, oder die Konfiguration eines vorhandenen Kanals wurde geändert. Die Durchführung einer Transaktion spielt keine Rolle.
Die „Wiederherstellung“ einer Lightning Node mit dem SCB beinhaltet allerdings, dass alle Kanal-Partner darum gebeten werden, einen force-close durchzuführen. Das kostet entsprechend Gebühren und ja, die Kanäle sind halt zu. Ein Problem gibt es dann, wenn ein Kanal-Partner diesen force-close nicht durchführt (zB weil seine/ihre Node gleichzeitig abgeraucht ist), denn dann bleiben die BTC im Kanal gelockt. Wenn beide Nodes nicht mehr lauffähig sind, für immer. Das ist der Grund, wieso ein Kanal mit hoher outbound-Liquidität [edit: hier stand vorher „inbound“, was natürlich falsch ist) ein Sicherheitsrisiko darstellt.
Davor kann man sich nur schützen, indem man nicht nur ein aktuelles SCB hat, sondern auch die channel.db. Letztere enthält tatsächlich den aktuellen Zustand des Kanals, also inklusive aller Transaktionen. Das gefährliche hieran ist jedoch, dass eine Verwendung dieser Datenbank dann gefährlich ist, wenn sie nicht definitiv auf dem aktuellsten Stand ist (denn dann veröffentlich man technisch gesehen einen veralteten Zustand, was zu den oben genannten penalty-Transaktionen führt). Raucht einem die Node ab, kann es ja sein, dass der letzte Schreibvorgang in diese Datenbank nicht mehr geklappt hat… Man kann aber auch das untersuchen und durch korrektes Vorgehen ausschließen, dass man funds durch penalty-transactions verliert: GitHub - guggero/chantools: A loose collection of tools all somehow related to lnd and Lightning Network channels.
2 „Gefällt mir“