Mein Lightning Tagebuch

silentpredator · 5. September 2025 um 05:35

die Story ist schon über, wenn man bedenkt wieviel Kohle das ist. Für normal-Sterbliche ist das ein Vermögen. Im Grunde genommen hatte er irgendwelche Probleme mit seiner lightning node und wollte support von den Betreibern von Amboss. Der Support war in einem Telegramm-Kanal und war anscheinend von mehreren Scammern und Bots besetzt. Er dachte er spricht mit den wirklichen Betreibern und die haben ihn über Stunden weich geredet bis sie ihn auf eine Seite gelots haben, wo er seinen seed eingeben sollte.

Es ist halt immer das gleiche. Entweder sollst du deinen seed preisgeben, deinen private key, oder du sollst dir direkt iregendeine Software installieren, die wie ein Trojaner und keylogger funktioniert und die Daten versendet.

Man kann immer wieder betonen, sich AUSGIEBIG mit der Materie zu befassen, bevor man irgendwas tut. Ein Grund warum ich bis jetzt nur eine full node laufen lasse und mir mit lightning noch etwas Zeit lasse. In Sachen Bitcoin kenne ich mich bereits aus und weiß welche Software es gibt und welche Stlopersteine existieren. Und ich werde auch erst lightning-Kanäle öffnen, wenn ich in Gänze verstanden habe was ich da tue.

satoshi_schueler21 · 5. September 2025 um 05:40

Da sollte schon alle ALARMGLOCKEN läuten!!!

Astrea · 6. September 2025 um 20:06

Woche 10: Endlich „live“, Charge-lnd, 2 Bitcoin und Urlaubsvorbereitungen

Ich bin endlich „live“. Der ein oder andere hat vielleicht bemerkt, dass ich bisher noch immer ein wenig hinterher war mit meinen Tagebucheinträgen. Ab jetzt seid ihr aber immer am Puls der Zeit – die Einträge zur aktuellen Woche gibt es künftig immer am Ende der Woche.

Gegen Ende dieser Woche geht es für mich in den Urlaub. Und auch wenn die Node zu Hause nicht ganz alleine ist, wird sie doch ohne aktives Management auf sich gestellt laufen müssen. Letzte Chance also, die tägliche Routine so weit wie möglich zu automatisieren. Bisher umfasst diese:

Prüfen, welche Weiterleitungen es seit dem letzten Check gab und ob sich dadurch die Liquidität verschoben hat → Gebühren anpassen
Schauen, ob jemand neue Kanäle zu mir eröffnet hat → diese zunächst auf 0 Basisgebühr und 1600 ppm setzen
Bei frischen Kanälen mit kompletter Liquidität auf meiner Seite die Gebühren nach dem Muster aus Woche 4 anpassen
Auf LN+ nach neuen Pool-Anfragen schauen
Auf LN+ prüfen, ob jemand meinen Swaps beigetreten ist bzw. ob neue Kanäle geöffnet werden müssen
Allgemeine Recherche (z. B. potenzielle Kanalpartner)
Node-Projekte

Einige Punkte kann ich auch unterwegs erledigen, z. B. Anfragen auf LN+ annehmen oder ein wenig Recherche. Aber Kanäle öffnen, Gebühren anpassen und neue Node-Projekte umsetzen – das wird eher nichts. Und keine Sorge: Auch die Tagebucheinträge wird es vom Urlaub aus geben, auch wenn sie vermutlich ein bisschen anders aussehen werden.

Da ich ohnehin erst mal langsamer machen wollte, beschließe ich, im Urlaub keine neuen Kanäle zu eröffnen. Bleibt also das Thema Gebühren. Schon länger wollte ich charge-lnd aufsetzen – und diese Woche ist es endlich so weit: das Wochenprojekt ist ein Tool für automatisches Gebührenmanagement.

Die Installation läuft erstaunlich reibungslos, und charge-lnd funktioniert sofort. Anfangs lasse ich es alle 5 Minuten laufen, reduziere dann aber auf alle 30 Minuten, da zu häufige Änderungen nur mehr fehlgeschlagene HTLCs erzeugen. Die eigentliche Arbeit liegt im Erstellen der Regeln:

Sinks: feste höhere Gebühr.
Sources: feste niedrige Gebühr.
Negative Gebühren: Standard von –100 ppm auf –200 ppm geändert, gleichzeitig ausgehende Gebühren um 100 ppm angehoben. So bleibt das Verhältnis gleich, nur kann ich höhere effektive eingehende Gebühren erheben.
Normale Kanäle: Gebühren zwischen 200 und 450 ppm, abhängig von der Liquiditätsverteilung. Zusätzlich senkt sich die Gebühr automatisch, wenn ein Kanal mehrere Tage keine ausgehenden Zahlungen hatte.

Am schwierigsten finde ich die Regeln für neue Kanäle. Ich habe keine gute Möglichkeit gefunden, diese automatisch zu kategorisieren. Daher lege ich eigene Regeln für die ersten drei Wochen neuer Kanäle an und übernehme danach wieder manuell. Am Ende ist meine Konfigurationsdatei über vier Seiten lang – aber es funktioniert. Und schon in den ersten Tagen nimmt mir charge-lnd spürbar Arbeit ab. Ich denke mir: Das hätte ich wirklich früher machen sollen. Ein großartiges Tool!

Neue Kanäle und die 2-BTC-Marke

Zu Beginn der Woche wird es noch einmal knapp: Ich muss die drei ausstehenden Kanäle aus Woche 9 öffnen und habe nur wenige Stunden Zeit. Einer der Swaps ist aber noch nicht voll – und ich würde so gerne alle Kanäle in einer einzigen Transaktion bündeln, um Gebühren zu sparen. Da bisher nur eine andere Node im Swap ist, beschließe ich, trotzdem zu öffnen: die drei Swap-Kanäle, den bereits geplanten Kanal zu The Continental und zusätzlich einen Kanal zur Node, die schon im Swap steht.

So darf ich Stinger32LND, kittyboy, The Continental, LightningNetworkLiquidity und fortuna-custody-stroom als neue Partner begrüßen. Kurz danach füllt sich auch der letzte Swap, und 03333700ea7dd48f2bdf eröffnet einen Kanal zu mir. Moment mal – mit der Node habe ich doch schon einen Kanal! Jetzt kommt also noch ein zweiter dazu. Ich bin zunächst etwas unzufrieden, da ich eigentlich neue Partner wollte. Doch er schreibt mir, er habe bewusst mitgemacht, weil meine Node gute Verbindungen hat und mehrere Kanäle ja kein Problem seien. Da hat er nicht ganz unrecht – trotzdem werde ich künftig klarer in die Swap-Regeln schreiben, dass nur Nodes ohne bestehende Kanäle beitreten sollen.

Im Laufe der Woche kommt noch eine 2M-Pool-Anfrage von XOTOR, die ich annehme. Und auch BTC_USA eröffnet spontan einen 2M-Kanal zu mir. Gleichzeitig schließt dharma-node ohne Vorwarnung alle Kanäle – offenbar wird die Node stillgelegt.

Am Samstag stehe ich bei ca. 1,92 BTC Gesamtkapazität. Ich entscheide mich, die 2-Bitcoin-Marke vollzumachen, kaufe ein paar Sats und eröffne einen großen Kanal zu cyberdyne.sh. Besonders spannend: Diese Node nutzt nicht nur negative, sondern auch positive eingehende Gebühren – etwas, das seit LND v0.18 möglich ist. Standardmäßig ist es deaktiviert, aber nach Aktivierung funktioniert es tatsächlich. Das eröffnet ganz neue Möglichkeiten. Ich nehme mir vor, im Urlaub darüber nachzudenken, wie ich diese Option sinnvoll einsetzen kann – vielleicht sogar mit einer komplett neuen charge-lnd-Konfiguration.

Fazit Woche 10

Automatisches Gebührenmanagement: Endlich eingerichtet – ich fahre beruhigt in den Urlaub.
Neue Kanäle: Einige spannende Partner, auch wenn doppelte Verbindungen nicht mein Ziel waren.
2-BTC-Marke: Ein schöner Meilenstein zum 10-Wochen-Jubiläum!
Neue Ideen: Positive eingehende Gebühren könnten künftig ein spannender Hebel sein.

Die Gesamtkapazität der Node am Ende der Woche beträgt ca. 2,03 BTC in 62 Kanälen.

Für die nächsten zwei Wochen gilt: keine neuen Kanäle von meiner Seite – aber Tagebucheinträge gibt es auch aus dem Urlaub, mal sehen, was mir einfällt.

Astrea · 14. September 2025 um 17:04

Woche 11: Gedanken zu Evolutionsstufen von Nodes und zur Rolle von Gebühren – und meine Node auf sich allein gestellt

Urlaub ist immer schön – aber schon am Morgen des zweiten Tages ertappe ich mich dabei, wie ich meine Lightning-Node ein wenig vermisse. Sie ist mir in kurzer Zeit zu einem echten Hobby geworden. Vielleicht ist es ein bisschen wie bei einem MMORPG: Man startet mit einem „leeren“ Charakter, sammelt durch Interaktion Erfahrungspunkte, rüstet sich mit neuen Fähigkeiten aus und entwickelt einen ganz eigenen Spielstil.

Überträgt man das Bild auf Lightning-Nodes, dann entspricht der Fortschritt der Gesamtkapazität, die Individualisierung den Kanalpartnern und -größen, und die Fähigkeiten den Tools wie charge-lnd oder LNDg. Und wie bei einem Rollenspiel-Charakter wächst einem die Node schnell ans Herz – man identifiziert sich mit ihr.

Die Gebührenstrategie wäre in dieser Analogie der „Spielstil“. Sie muss ständig angepasst werden, denn auch die anderen Spieler (Nodes) verändern ihre Strategien, erschließen neue Routen oder passen Gebühren an. So kann eine Source-Node durch neue Verbindungen oder Strategiewechsel zur Sink-Node werden – und umgekehrt.

Evolutionsstufen einer Routing-Node

Je mehr ich diese Woche darüber nachdachte, desto klarer wurde mir: Mit der Zeit rückt das Gebührenmanagement immer stärker in den Vordergrund. Ich stelle mir die Entwicklung einer Routing-Node ungefähr so vor:

Stufe 1: Erste Kanäle werden eröffnet. Der Fokus liegt auf Wachstum und dem Erlangen von Inbound-Liquidität, um überhaupt weiterleiten zu können.
Stufe 2: Suche nach Partnern, die möglichst wenige gemeinsame Verbindungen haben, um neue Routen zu erschließen. Wachstum (z. B. via Swaps) steht im Mittelpunkt.
Stufe 3: Beobachtung der etablierten Routen und erste Optimierung der Gebühren.
Stufe 4: Aktives Schließen schlecht performender oder redundanter Kanäle und Reallokation der Sats in attraktivere Kanäle.
Stufe 5: Monetarisierung durch den Verkauf von Liquidität – etwa über Amboss/Lightning Terminal/Bos oder mit einem eigenen LSP-Service. Zudem bekommen große und attraktive Nodes ohnehin viel Inbound-Liquidität und können diesen Überschuss profitabel ableiten, z. B. durch Kanäle zu bekannten Sinks wie LOOP.

Nach dieser Logik würde ich meine Node aktuell auf Stufe 3 einordnen.

Sink-Nodes neu gedacht

Besonders spannend finde ich die Überlegung, dass Kanäle zu Sinks wie LOOP vielleicht gar nicht „böse Spinnen-Nodes“ sind, die anderen absichtlich Liquidität absaugen (wie es im Artikel Fruit of the LOOP beschrieben und von mit in Woche 4 behandelt wird).

Es könnte auch einfach eine natürliche Folge der Attraktivität dieser Nodes sein: Sie erhalten so viel Inbound-Liquidität, dass sie diese „ableiten“ müssen, um weiterhin ausgeglichene Routen anbieten zu können. In diesem Bild wären diese Kanäle eher eine Art passives Kühlsystem, das überschüssige Liquidität zu LOOP und Co. ableitet – und dabei natürlich etwas verdient. Damit bekommt das Wort “SINK-Node” eine ganz neue Bedeutung

Das lässt mich meine frühere Haltung revidieren: Große Kanäle zu LOOP oder Fixedfloat sind vielleicht nicht pauschal problematisch, sondern können eine natürliche Folge der Evolution erfolgreicher Nodes sein.

Gedanken zum Gebührenmanagement

Auch viel über meine Gebührenstrategie habe ich in dieser Woche nachgedacht. Die aktuelle Strategie funktioniert zwar, aber sie reagiert kaum auf Veränderungen im Netzwerk. Eine „ideale Lösung“ müsste:

Kanäle und Weiterleitungen beobachten,
daraus Schlüsse ziehen,
Kanalpartner kategorisieren (Sink, Source, etc.),
dynamisch die passende Gebühr ermitteln,
und das Ganze regelmäßig rekalibrieren.

Das ist komplex – und charge-lnd stößt hier an Grenzen. Es berücksichtigt weder die Historie von Gebühren noch die Erfolgsquote bestimmter Gebührenbereiche. Eine Idee wäre ein Programm, das kontextabhängig eine charge-lnd-Konfiguration generiert und regelmäßig aktualisiert.

Das Problem: Ich bin kein Entwickler. Meine Erfahrung beschränkt sich auf etwas PHP-Bastelei in meiner Jugend. Also wäre es ein längerfristiges Lernprojekt – spannend, aber nicht kurzfristig umsetzbar. Fürs Erste bleibt es dabei, meine Strategie innerhalb von charge-lnd weiter zu optimieren.

Node-Status dieser Woche

Meine Node läuft während des Urlaubs unauffällig. Über amboss.space sehe ich: keine geschlossenen oder neu eröffneten Kanäle, und sie ist durchgehend aktiv.

Auf LN+ bekomme ich eine Pool-Anfrage von „none“: 14,6M Sats. Die Node arbeitet jedoch mit sehr simpler Gebührenstruktur (200 oder 400 ppm). Meine Erfahrung ist, dass solche Partner oft nur einseitig routen. Außerdem ist mir der Kanal etwas groß – meine Credits setze ich lieber für mehrere kleinere Kanäle ein. Entscheidung steht noch aus, Tendenz: Ablehnung.

Fazit Woche 11

Gedanken: Nodes entwickeln sich in Stufen; Gebührenmanagement wird mit jeder Stufe wichtiger.
Neue Perspektive: Kanäle zu Sinks wie LOOP könnten mehr nutzen als schaden – vielleicht sind sie einfach Ventile für überschüssige Liquidität.
Strategie: Charge-lnd reicht für komplexe Modelle nicht, hat aber noch ungenutztes Potenzial.
Node-Status: Alles stabil, keine Überraschungen.

Für nächste Woche nehme ich mir vor, einen konkreteren Plan für die Gebührenstrategie zu entwickeln – vielleicht hilft ein Flowchart, die Logik zu strukturieren.

Die Gesamtkapazität der Node am Ende der Woche beträgt weiterhin ca. 2,03 BTC in 62 Kanälen.

Astrea · 22. September 2025 um 20:50

Woche 12: Meine Node zwei Wochen ohne Eingreifen, der erste große eingehende Kanal und Pool-Aktivität

Auch in der zweiten – und letzten – Urlaubswoche beobachte ich meine Node über amboss.space ein wenig aus der Ferne. Obwohl es insgesamt recht ruhig bleibt, taucht am Dienstag ein neuer Kanal auf. Und was für einer! LNBiG [Hub-1] eröffnet aus heiterem Himmel einen 10M-Sats-Kanal zu mir. Das ist der erste große Kanal, den eine andere Node zu meiner öffnet. Offenbar hat meine Node inzwischen eine Größe bzw. Attraktivität erreicht, bei der auch größere Nodes größere Kanäle mit mir haben wollen – und das fühlt sich verdammt gut an.

Ansonsten passiert diese Woche kanaltechnisch wenig. Als ich am Wochenende nach Hause komme, gibt es noch zwei Pool-Anfragen: Bee Tee See und VIVA La Lightning möchten jeweils einen 10M-Sats-Kanal zu mir eröffnen.

Bei VIVA La Lightning fällt mir die Entscheidung leicht: Die Node ist seit über 5 Jahren aktiv, wir haben nur wenige gemeinsame Kanalpartner, und die Gebührenstruktur scheint fair. Ich nehme also an.
Bei Bee Tee See sieht es anders aus: Diese Node hat mehrere große Kanäle zu LOOP, die regelmäßig erneuert werden. Die Gebührenstruktur scheint in Ordnung, aber wir haben bereits viele gemeinsame Kanalpartner. Nach einigem Überlegen entscheide ich mich dennoch für die Annahme. Schließlich will ich durch dieses Experiment etwas lernen – das Schlimmste wäre, die 10M Pool-Credits zu verlieren und dass der Kanal nicht weiterleitet.

Node-Aktivität während meiner Abwesenheit

Natürlich interessiert mich brennend, was die Node in meiner Abwesenheit getrieben hat. Einige Beobachtungen:

Kanal zu Kraken: Dieser ist wieder leer. Als ich ging, war der Großteil der Liquidität auf meiner Seite; jetzt auf der anderen. Das trotz leicht erhöhter Gebühren.
Gewinn- und Verlustanzeige: Zeigt wieder einen Gesamtverlust an – zunächst verwirrend, aber im Zusammenhang mit Rebalancing nachvollziehbar.
Kanal zu c-otto.de: Fast die komplette Liquidität auf meiner Seite. Normalerweise war es genau umgekehrt. Die Anpassungen durch Rebalancing verursachen einige Sats an Verlusten. Ich passe die Gebühren an und werde den Kanal in den nächsten Tagen beobachten.
Einige zuvor volle Kanäle: Jetzt leer – dafür richte ich direkt separate Gebührenregeln ein.
Einige Kanäle: Funktionieren weiterhin organisch in beide Richtungen und halten sich selbst im Gleichgewicht – die liebsten Kanäle für mich.

Gebühren-Management

Das Flowchart-Projekt von letzter Woche habe ich zunächst auf unbestimmte Zeit verschoben – es ist umfangreicher als gedacht.

Eine größere Änderung setze ich aber gleich um: Ich stelle positive eingehende Gebühren für drei Source-Kanäle ein und passe alle anderen Gebühren so an, dass die neue Standard-Gebühr für eingehende Zahlungen 0 ppm beträgt (vorher -200 ppm, um effektiv positive Gebühren zu simulieren).

Ich bin gespannt, ob dadurch:

die Weiterleitungen zunehmen,
die Kanäle mit positiven Gebühren mehr Fehlgeschlagene HTLCs produzieren, da positive eingehende Gebühren noch nicht von allen Nodes vollständig unterstützt werden.

Fazit Woche 12

Eine eher ruhige Woche, aber es ist beruhigend zu sehen, dass die Node auch ohne manuelles Eingreifen aktiv Zahlungen weiterleitet, ohne in größere Liquiditätsprobleme zu geraten. Es waren die ersten beiden Wochen, in denen ich keine neuen Kanäle geöffnet habe, und die Node hat es gut gemeistert.

Besonders erfreulich: der erste große Kanal von einer anderen Node wurde eröffnet.

Für die nächste Woche nehme ich mir vor, genau zu beobachten, welche Auswirkungen die Gebührenänderungen – insbesondere die positiven eingehenden Gebühren – haben. Außerdem freue ich mich darauf, wenn Bee Tee See und VIVA La Lightning ihre 10M-Kanäle öffnen, denn dann habe ich genau 10 große Kanäle zu je 10M Sats, also 1 BTC Gesamtkapazität in großen Kanälen zu großen Nodes.

Die Gesamtkapazität der Node am Ende der Woche beträgt ca. 2,13 BTC in 63 Kanälen.

Astrea · 12. Oktober 2025 um 21:23

Woche 13, 14 & 15 – Auswirkungen positiver eingehender Gebühren, geplante Upgrades und der Weg zur Top 100 Node

Bitte entschuldigt, dass der Tagebucheintrag in den letzten beiden Wochen krankheitsbedingt ausgefallen ist. Jetzt bin ich wieder fit und fasse Woche 13, 14 und 15 in diesem Eintrag zusammen.

Gleich zu Beginn von Woche 13 öffnen Bee Tee See und VIVA La Lightning ihre 10M-Sats-Kanäle zu mir – ein wunderbarer Start in die Woche.
Im Laufe der beiden Wochen folgen weitere LN+ Pool-Anfragen von U got IT (5 Millionen Sats), Babylon-4a (10 Millionen Sats) und LNDWarden (5 Millionen Sats), die ich alle annehme, da es sich um größere, gut vernetzte Nodes handelt, die neue Routen mitbringen.

Eine weitere Anfrage von BitCoinHawaalah über 2,5 Millionen Sats lehne ich ab, da die Node nur wenige Kanäle hat und bei Lightning Terminal nicht als „Good Node“ gelistet ist.
Und dann eröffnet Megaflash, eine ganz frisch gestartete, aber rasant wachsende Node, völlig überraschend einen 2,1-Millionen-Sats-Kanal zu mir – sehr erfreulich.

Leider gibt es auch ein paar Kanalschließungen: noodle:victory_hand:redux:high_voltage: scheint alle Kanäle und damit auch die eigene Node proaktiv zu schließen – schade, denn unser Kanal war erst Ende August entstanden.
Besonders bedauerlich ist, dass Corn🌽gosumi🦔, einer meiner ersten Kanalpartner, offenbar ein Problem mit seiner Node hatte und den Recovery-Prozess gestartet hat. Dadurch werden alle seine Kanäle – auch unserer – „Force Closed“. Der Force Close kommt technisch gesehen von meiner Seite, weil ich auf seine Recovery-Anfrage reagiere. Standardvorgehen, aber dennoch schade.
Vielleicht baut er seine Node ja wieder auf; ich nehme mir vor, das im Auge zu behalten.

Hier der finale Auszug der Kanalpartnerschaft zwischen mir und Corn🌽gosumi🦔:

Neue Kanäle und Beobachtungen

Mit den Sats aus den geschlossenen Kanälen eröffne ich per LN+ Pool-Anfrage einen neuen 2M-Kanal zu Absolem. Zwar hat diese Node eine etwas kleinere Gesamtkapazität, dafür aber viele Kanäle – auch zu Nodes, zu denen ich bisher keine Verbindung habe.

Einen weiteren Kanal öffne ich zu Kraken. Moment mal – zu Kraken habe ich doch schon einen?
Stimmt, aber bisher war es nur ein kleiner mit 2M Sats. Der neue Kanal hat 10M Sats.

Der Grund: Ich habe die Gebührenstruktur von Kraken über mehrere Wochen beobachtet, und sie scheint dynamisch zu reagieren:

2500 ppm, wenn fast die gesamte Liquidität auf meiner Seite ist
1000 ppm, wenn deutlich mehr Liquidität auf meiner Seite liegt
500 ppm, wenn der Kanal weitgehend ausgeglichen ist
100 ppm, wenn fast die gesamte Liquidität auf der Seite von Kraken ist

Ich gehe also davon aus, dass Kraken bereits bei wenigen Hunderttausend Sats auf meiner Seite auf 100 ppm heruntergeht, um wieder Liquidität zurückzuholen – und das funktioniert tatsächlich.
Nach einigen Tagen sehe ich den Effekt deutlich.

Allerdings schließt Kraken nach rund 14 Tagen in Woche 15 den neuen 10M-Kanal wieder. Mein kleiner 2M-Kanal bleibt dagegen offen. Ich bin etwas ratlos: Bei beiden lag die Liquidität zuletzt fast komplett auf der Seite von Kraken, und bisher hatte Kraken so einen Kanal nie geschlossen.
Vielleicht liegt es daran, dass ich zwei Kanäle gleichzeitig offen hatte?

Kurzerhand besorge ich mir also wieder 10M Sats, schließe den kleinen Kanal und eröffne erneut einen großen mit 10M. Mal sehen, ob dieser bleibt – es bleibt jedenfalls spannend.

Zum Ende von Woche 15 schließt dann auch cyberdyne.sh seinen 10M-Kanal mit mir. Das enttäuscht mich etwas, denn der Kanal hat gut performt – nur zwei Stunden vor dem Close ging noch eine Zahlung über rund 1,5M Sats an Kraken durch.
Meine Node hatte in letzter Zeit keine Ausfälle, also schreibe ich dem Betreiber über die Kontaktadresse auf der Website eine kurze E-Mail, frage nach dem Grund und ob ich etwas besser machen kann. Besonders interessiert mich, ob es vielleicht an den positiven eingehenden Gebühren lag, die ich dort eingestellt hatte. Die Antwort steht noch aus.

Hier ein Bild dazu, wie gut der Kanal funktioniert hat – häufig liefen in kurzer Zeit Zahlungen in beide Richtungen, ganz ohne mein Zutun:

Hardware-Upgrade

Langsam mache ich mir ein wenig Sorgen um meine Hardware. Nicht, dass etwas akut wäre, aber mein Raspberry Pi 5, auf dem die Node läuft, nutzt noch immer eine SD-Karte – und die sind im Dauerbetrieb bekanntlich nicht besonders langlebig.
Zwar liegen die meisten Apps und Daten bereits auf einer externen SSD, aber ein Schreibfehler im falschen Moment – etwa in der Kanal-Datenbank – könnte zu einer Beschädigung führen, die im schlimmsten Fall einen kompletten Recovery-Prozess notwendig macht. Das wäre kein finanzieller Verlust (abgesehen von den Schließgebühren), aber ein massiver Rückschlag.

Ich entscheide mich also für ein Upgrade: Alles auf eine NVMe.
Nach kurzer Recherche finde ich ein in das Gehäuse passendes NVMe-Upgrade-Kit für den Pi. Eine 2TB-NVMe wird schnell bestellt und geliefert.
Ich überlege noch, wie ich die Daten am besten übertrage – komplett neu installieren und nur die App-Daten übernehmen, die SD-Karte klonen oder doch eine Mischlösung? Noch bin ich unschlüssig, aber das Upgrade will ich kommende Woche umsetzen.

Langfristig wird die Node vermutlich ohnehin auf leistungsfähigere Hardware umziehen, aber das NVMe-Upgrade sollte vorerst für Ruhe sorgen.

Auf dem Weg zur Top 100

Früh in Woche 13 setze ich mir ein neues Ziel: Mit meiner Node in die Top 100 bei Lightning Terminal zu kommen.
Die Bewertungskriterien dort erscheinen mir sinnvoll, und ich hoffe, dadurch noch mehr Aufmerksamkeit und Kanaleröffnungen von anderen Nodes zu bekommen.

In Woche 13 liege ich noch etwa auf Platz 150, komme in Woche 14 aber immer näher an die 100 heran. In Woche 15 schaffe ich es sogar kurzzeitig auf Platz 97, falle dann aber wieder zurück.

Lightning Terminal bewertet unter anderem, wie „gut“ die eigenen Kanalpartner sind – also wie stabil sie online sind, wie viele gute Verbindungen sie selbst haben und wie aktiv sie routen.
Sind meine Partner gerade stabil, geht es nach oben; sind einige offline, wieder nach unten. Meist bewege ich mich zwischen Platz 100 und 150.

Die Lösung ist klar: mehr gute Kanalpartner.
Ich nehme mir vor, künftig vor jeder neuen LN+ Pool-Anfrage auch Lightning Terminal zu prüfen.

Auswirkungen der positiven eingehenden Gebühren

Die Änderung der Gebührenstruktur hat spürbare Auswirkungen. Insgesamt gibt es deutlich mehr Weiterleitungen – allerdings mit einem größeren Anteil an Zahlungen mit sehr niedrigen oder gar keinen Gebühren.

Das hat Vor- und Nachteile: Einerseits verdiene ich weniger pro Weiterleitung, andererseits hilft es, Kanäle besser auszubalancieren, da günstige Gebühren vor allem dort wirken, wo ohnehin viel Liquidität auf meiner Seite liegt.

Die positiven eingehenden Gebühren hingegen sind ein zweischneidiges Schwert. Einige Nodes – insbesondere ältere LND-Versionen sowie CLN- und Eclair-Implementierungen – unterstützen sie nicht korrekt. Das führt zu vielen fehlgeschlagenen HTLCs auf diesen Kanälen.
Ich überlege daher, ob ich vorerst wieder auf das alte System mit negativen Gebühren zurückwechsle oder diese Kanäle einfach auf 0 setze.

Fazit Woche 13–15

Das Wachstum meiner Node hat sich zuletzt verlangsamt. Der letzte große Sprung war in Woche 10, danach kamen nur noch wenige neue Kanäle hinzu – netto vier in den letzten drei Wochen mit insgesamt 37M Sats, die meisten davon durch eingehende Pool-Anfragen.
Meine LN±Credits gehen nun langsam zur Neige.

Ich möchte wieder etwas mehr Schwung rein bringen und plane daher, meine Node in den kommenden Tagen um einen ganzen Bitcoin aufzustocken – hauptsächlich über neue LN±Pool-Kanäle. Darauf freue ich mich schon sehr und habe mir bereits einige vielversprechende Partner notiert.

Zum Abschluss noch ein Statistik-Auszug zu meiner Node:

Gesamtkapazität am Ende von Woche 15:
ca. 2,50 BTC in 67 Kanälen.

Tutulla · 13. Oktober 2025 um 06:18

Daran wirst du dich gewöhnen müssen. Meine Node ist jetzt ca. 5 Jahre alt und habe über 170 geschlossene Kanäle. Von meiner Seite wurde keiner bewusst geschlossen, außer die Partnernode war über 1 Monat offline.

Tagebuch Top wie immer.

Astrea · 13. Oktober 2025 um 20:01

5 Jahre!? Wow, beeindruckend. Ich bin gespannt, ob ich auch so weit komme. Da ich auch nach über drei Monaten noch motiviert bin, sieht es aber ziemlich gut aus.

Natürlich werden Kanäle manchmal einfach von der anderen Seite geschlossen. Wenn die Node komplett heruntergefahren wird oder ein Recovery mit Neustart nötig ist, ist das nachvollziehbar und unvermeidbar.
Bei Kanalschließungen, deren Grund nicht sofort ersichtlich ist, möchte ich allerdings genauer hinschauen, um zu lernen, ob es an mir lag, was ich verbessern könnte und wie man so etwas vielleicht von vornherein verhindern kann.

Der Betreiber von cyberdyne.sh hat übrigens inzwischen geantwortet – die Details dazu gibt es aber erst im nächsten Tagebucheintrag

Tutulla · 14. Oktober 2025 um 08:03

Betreibe auch nicht dein Aufwand, Respekt.
Bei mir läuft 2 mal täglich charge-lnd wegen der Gebühren und natürlich prüfen und einspielen von Updates.
Mit den Sats von geschlossen Kanälen öffne ich wieder neue Kanäle, neue Sats fließen nicht mehr rein.
Bezahlen tue ich hauptsächlich bei Bitrefill (Prepaid-Guthaben und Gutscheine für Online und Offline-Einkäufe).

Bin mal gespannt, zu cyberdyne.sh hab ich auch ein Kanal.

Astrea · 19. Oktober 2025 um 19:47

Woche 16 – Das NVMe-Upgrade, viele Rückschläge und ein kleiner Triumph

Die Woche startet mit einem klaren Ziel: Ich möchte einen zusätzlichen ganzen Bitcoin in meine Node stecken.
Doch bevor ich das tue, steht noch ein anderes Vorhaben an – das Upgrade von SD-Karte + externer SSD auf eine M.2 NVMe.
Ich entscheide mich, das Upgrade zuerst durchzuführen. Sollte dabei etwas schiefgehen und ich den Recovery-Prozess starten müssen, würden ohnehin alle Kanäle geschlossen. Da wäre es wenig sinnvoll, vorher neue Kanäle zu öffnen, die dann direkt wieder verschwinden.

Die Hardware habe ich bereits letzte Woche besorgt und starte am Montagmorgen mit folgendem Plan:

Klonen der SD-Karte auf die NVMe
Vergrößern der relevanten Partitionen
Kopieren der Daten von der externen SSD auf die NVMe
Einbau der NVMe-Hardwareerweiterung in den Raspberry Pi
Wiederinbetriebnahme der Node mit NVMe

Jetzt wird’s etwas technischer – wer mag, darf diesen Teil gerne überspringen.

Montag – Das missglückte Upgrade

Gegen 12:30 Uhr beginne ich mit der Umsetzung. Ich fahre die Node herunter, verbinde die NVMe über einen USB-Adapter mit meinem Laptop und stecke die SD-Karte ein.
Das Klonen mit dd dauert länger als erwartet. Nach etwa 40 Minuten ist der 32GB-Klon fertig, die Partition angepasst, und ich schließe die externe SSD an.
Doch beim Kopieren der Daten mit rsync verabschiedet sich die NVMe regelmäßig nach wenigen hundert Megabyte – sie reagiert einfach nicht mehr. Nur ein Ab- und Anstecken hilft kurzfristig, aber nach kurzer Zeit tritt der Fehler erneut auf.
Das Klonen mit dd hatte problemlos funktioniert, also verstehe ich nicht, woran es liegt.

Das Upgrade ist also zunächst gescheitert.
Ich verbringe zwei Stunden mit Fehlersuche, bevor ich gegen 16:30 Uhr aufgebe und die Node wieder im alten Zustand mit SD-Karte + externer SSD starte.

Doch jetzt taucht ein neues Problem auf: Mein Bitcoin Core steckt in „pre-synchronizing“ fest.
Zuerst fürchte ich, die Blockchain-Daten könnten beschädigt sein.
Nach einiger Zeit entdecke ich in den Logs jedoch den Hinweis: „Verification progress 16%“. Es hängt also nicht fest – es ist einfach nur unglaublich langsam.
Etwa 20 Minuten später ist die Node synchronisiert, aber ich bekomme keine Peers. Jeder Neustart führt erneut zu 15–20 Minuten „Verification“.
Als ich endlich ein paar Peers finde, dauert jeder Block mehrere Minuten. Das war früher nie so.
Erst spät am Abend läuft die Node wieder halbwegs normal.
Immerhin scheint nur Bitcoin Core betroffen zu sein, LND und die anderen Umbrel-Apps funktionieren weiterhin.

Dienstag – Neuer Plan, neue Hoffnung

Am Dienstag steht Plan B:

NVMe formatieren
SD-Karte erneut auf NVMe klonen
Node wieder mit SD-Karte + externer SSD starten
Partitionen auf der NVMe vergrößern
Blockchain über das lokale Netzwerk auf die NVMe kopieren (bei laufender Node)
Node herunterfahren
SSD mit Laptop verbinden und restliche Daten kopieren
NVMe-Hardwareerweiterung einbauen
Node mit NVMe starten

Ziel: kürzere Downtime, weil die Blockchain (der größte Datenteil) bereits im Hintergrund übertragen wird.

Nachmittags geht’s los. Das Klonen klappt erneut problemlos.
Doch das Problem mit dem langsamen „Verification progress“ bleibt bestehen. Wenigstens kann ich die Blockchain jetzt über das Netzwerk übertragen – leider nur über WLAN, da mein Laptop keinen RJ45-Anschluss hat.
Also läuft der Kopiervorgang die halbe Nacht, aber immerhin fehlerfrei.

Mittwoch – Erfolg und Frust zugleich

Mittwochmorgen will ich endlich fertig werden. Ich fahre die Node herunter, verbinde die SSD mit dem Laptop und starte den Kopiervorgang der restlichen Daten mit rsync.
Und wieder: die NVMe verabschiedet sich.
Ich verstehe es nicht – das Kopieren der Blockchain hat doch auch funktioniert!
Nach kurzer Verzweiflung mache ich Pause, und mit klarem Kopf fällt mir etwas auf:
Vielleicht ist das Problem gar nicht rsync, sondern die Geschwindigkeit.
Die Kopie von der SSD zur NVMe läuft deutlich schneller als das vorherige Klonen oder die WLAN-Übertragung.
Ich begrenze rsync also auf 30 MB/s – und siehe da: es funktioniert! Keine Fehler mehr, nur dauert alles ewig.

Gegen Nachmittag ist alles kopiert. Ich baue die NVMe in den Raspberry Pi ein, starte – und nichts passiert. Kein Netzwerk, keine Erkennung, keine Reaktion.
Ich teste die NVMe in einem anderen Pi, der sicher NVMe-bootfähig ist – ebenfalls nichts.
Das Upgrade ist erneut gescheitert.

Also wieder zurück zu SD-Karte + SSD.
Bitcoin Core braucht weiterhin 15–20 Minuten zum Start und lädt Blöcke extrem langsam.
Erst spät am Abend ist alles wieder online – und ich bin froh, dass kein Kanalpartner während der langen Offlinezeit geschlossen hat.
Ein neuer Plan muss her.

Donnerstag – Der Durchbruch

Am Donnerstag starte ich einen neuen Versuch:
Ich lösche die NVMe und spiele ein frisches Umbrel-Image auf. Dann teste ich sie in einem separaten Pi – und siehe da, sie funktioniert!
Also liegt es nicht an der NVMe.

Ich installiere Bitcoin Core, stoppe die App und lösche die App-Daten.
Dann kopiere ich mit rsync die Blockchain von meiner laufenden Node – dieses Mal über LAN, was alles deutlich schneller macht.
Nach etwa drei Stunden ist die Übertragung abgeschlossen und ich kopiere den Rest bei ausgeschalteter Node.
Ich starte Bitcoin Core – und es funktioniert!

Der Unterschied ist unglaublich:

Alte Node:

Neue Node:

Alt: ca. 17 Minuten „Verification progress“, 23 Minuen Synchronisation
Neu: etwa 2 Sekunden „Verification progress“, 8 Sekunden Synchronisation

10 Sekunden vs. 40 Minuten vom Start bis zur vollständigen Synchronisation. Ich bin begeistert und mache gleich weiter: auch Electrs und Mempool laufen nach der gleichen Methode perfekt.

Nun wage ich mich an den kritischen Teil: LND.
Ich erinnere mich noch an Sayo (Woche 3), der versehentlich zwei Instanzen seiner Node gleichzeitig online hatte – mit fatalen Folgen. Das will ich unbedingt vermeiden.

Mein Plan:

Installation aller verbleibenden Apps (inkl. LND)
Löschen der App-Daten
Deaktivieren aller Apps auf beiden Nodes
Kopieren der App-Daten von alt → neu
Aktivieren von LND, LNDg und LNbits auf der neuen Node
Wenn alles funktioniert: Deinstallation aller Lightning-Apps auf der alten Installation

Donnerstagabend ist es so weit. Ich führe alles durch, aktiviere LND – und Erfolg!
Die Node startet sofort, verbindet sich mit allen Kanalpartnern, Thunderhub und RTL funktionieren, LNbits ebenfalls.
Nur LNDg zickt: Passwort ungültig.
Ich teste das alte Passwort – funktioniert.
Ich beschließe, das später zu lösen, deinstalliere die Lightning-Apps auf der alten Installation und mache erst mal Pause.

Freitag – Feinschliff und Passwort-Abenteuer

Am nächsten Tag baue ich alles ordentlich ins Gehäuse ein und gehe das LNDg-Passwortproblem an.
Umbrel oder LNDg bieten keine Möglichkeit, das Passwort zu ändern.
Ich finde die SQLite-Datenbank und sehe den gehashten Passwortwert.
Also versuche ich, denselben Hash zu erzeugen – aber ohne Erfolg.
Die Hashfunktion scheint etwas mit Django zu tun zu haben, aber ich bekomme keinen identischen Hash hin.

Dann kommt mir eine Idee:
Ich erstelle ein Backup der LNDg-Daten, deinstalliere die App, installiere sie neu und logge mich mit dem neuen Umbrel-Passwort ein – funktioniert!
Ich kopiere den neuen Passwort-Hash aus der Datenbank, stelle das Backup mit den alten Einstellungen wieder her und ersetze dann nur den Hash.
App neu starten, Login testen – Erfolg!
Neues Passwort, alte Einstellungen. Perfekt.

Samstag – Alles läuft… fast

Alles funktioniert wieder – bis auf meine Bolt Card.
Sie will nicht, aber ich beschließe, das Thema auf nächste Woche zu verschieben.
Auch ein kleines Problem mit der Bitcoin-Core-App bleibt erst mal liegen.
Wichtig ist: Die Node läuft, stabil und schnell.

Leider bin ich durch die langen Offlinezeiten auf Lightning Terminal von Platz ~100 auf etwa Platz 1700 gefallen.
Das wird wohl etwas dauern, bis sich das erholt.
Deshalb verschiebe ich den geplanten Bitcoin-Zufluss auf nächste Woche.
Wenn der Rang wieder besser ist, werden auch gute Pool-Anfragen und Swap-Partner einfacher zu finden sein.
Der Bitcoin dafür ist jedenfalls schon bereit.

Die Antwort von cyberdyne.sh

Zum Schluss noch die Antwort von Silen, dem Betreiber von cyberdyne.sh.
Er bestätigt, dass er den Kanal tatsächlich wegen der positiven eingehenden Gebühren geschlossen hat.
Nicht, weil seine Node sie nicht versteht – sondern weil sein Rebalancing-Tool damit nicht umgehen kann.
Er habe dadurch zu viel für Rebalancing bezahlt und wollte mich eigentlich kontaktieren, fand aber keine Kontaktmöglichkeit.
Vor dem Schließen stellte er sicher, dass fast die gesamte Liquidität auf meiner Seite liegt – sehr fair!
Er ist grundsätzlich offen für einen neuen Kanal, bittet aber darum, dass ich positive eingehende Gebühren nicht über 25 ppm setze.
Das werde ich selbstverständlich berücksichtigen – beim nächsten Batch-Opening.

Ach ja, und während des ganzen Chaos hat Sally Acorn spontan einen 2M-Sats-Kanal zu mir geöffnet – da hatte ich wohl Glück, dass die Node gerade online war.

Fazit

Diese Woche war technisch anspruchsvoll, anstrengend und frustrierend – aber auch unglaublich lehrreich.
Ich habe viel über Umbrel, seine Verzeichnisstruktur und das Zusammenspiel der Apps gelernt.
Sollte ich irgendwann erneut migrieren, z. B. auf ein x86-System, weiß ich jetzt genau, wie ich vorgehen muss – und würde sicher deutlich schneller ans Ziel kommen.

Leider war ich diese Woche kein besonders guter Kanalpartner.
Durch die langen Offlinezeiten waren viele Kanäle unbenutzbar.
Falls jemand hier mitliest, der einen Kanal mit mir hat: Sorry dafür – ab jetzt sollte es wieder stabil laufen.

Mein Ziel, einen weiteren Bitcoin einzusetzen, habe ich nicht erreicht – nicht einmal begonnen.
Aber am Ende zählt: Das Upgrade hat funktioniert, und meine Node ist bereit für die nächsten Schritte.

Die Gesamtkapazität der Node am Ende der Woche beträgt ca. 2,52 BTC in 68 Kanälen.

Astrea · 28. Oktober 2025 um 16:49

Woche 17 – Neue Verbindungen, alte Bekannte und Systemoptimierung

Die Woche fängt ruhig an. Ich beobachte meine Node aufmerksam, um sicherzugehen, dass nach der Migration auf die NVMe alles stabil läuft.
Noch am Samstagabend hatte ich die Einstellungen von Bitcoin Core zurückgesetzt, nachdem es zweimal abgestürzt war. Danach läuft bis Mittwoch alles gut – bis erneut ein Bitcoin-Core-Crash auftritt. Zum Glück bemerke ich ihn schon nach etwa drei Stunden.

Ich erinnere mich daran, dass ich seit der Migration generell eine höhere RAM-Auslastung bemerkt habe. Alles deutet darauf hin, dass es sich um einen „Out of Memory“-Error (OOM) handelt, auch wenn die Logs nicht ganz eindeutig sind.
Zunächst überlege ich, ob ich weniger wichtige Apps wie Mempool oder Electrs deaktivieren soll, entscheide mich dann aber erst einmal herauszufinden, wie groß die Swap-Datei eigentlich ist.
Zu meiner Überraschung gibt es gar keine.

Kurzerhand lege ich eine 4GB-Swap-Datei an – und Umbrel nutzt sie sofort aktiv. Sehr gut! Wenn es tatsächlich ein OOM-Problem war, dürfte das jetzt behoben sein. Ich beobachte das System weiter, bin mir aber ziemlich sicher, dass sich das Problem damit erledigt hat.

Bewegung im Lightning-Netzwerk

Abseits der Systempflege geht es diese Woche im Lightning-Netzwerk ziemlich wild zu – zumindest aus meiner Perspektive. Ich sehe viele große Transaktionen, teilweise mit erstaunlich hohen Gebühren, durch meine Node rauschen:

Neue Pool-Anfragen & Kanalöffnungen

Ich beginne außerdem damit, eine Liste potenzieller LN+ Pool-Anfragen zu erstellen.
Es sind weniger als gedacht – einige Kandidaten fallen raus, weil sie entweder unattraktive Gebühren (z. B. 0 ppm oder 2500 ppm), zu wenige Kanäle (unter 20), zu geringe Gesamtkapazität (unter 0,5 BTC) oder schlicht zu wenig LN+ Credits haben.
Am Ende bleiben 17 Nodes übrig, keine davon besonders groß, aber solide.

Ich beschließe, endlich damit zu beginnen, meinen zusätzlichen Bitcoin in neue Kanäle zu investieren – auch wenn sich mein Rang auf Lightning Terminal noch nicht wirklich erholt hat.

Ich stelle Anfragen an:

satsquares (3M Sats)
ChurchOfBitcoin (3M Sats)
Unchained Satoshis (3M Sats)
MAGNUS (3M Sats)
Bit2Cash (3M Sats)
SovereignSats (3M Sats)
Corn🌽Gosumi🦔 (3M Sats)
Skyweir (2M Sats)
StormFront (2M Sats)
Born To Run Knotsdes:knot: (2M Sats)
Naha (2M Sats)
WarsoWerk.de (2M Sats)
zehkstoshi (2M Sats)
21M (2M Sats)
FreebirdFreedomNode (2M Sats)
NOMOS (2M Sats)
BrokenThunder⚡ (2M Sats)

Sechs davon nehmen meine Anfrage zeitnah an.
Am Donnerstag eröffne ich alle Kanäle – plus einen neuen 10M-Sats-Kanal zu cyberdyne.sh – in einer einzigen Transaktion über LNDg, um Gebühren zu sparen.

Am Freitag folgt die zweite Runde: weitere vier angenommene Anfragen sowie zwei neue Kanäle zu Vix18 und Denaro Libre aus LN+ Swaps.

Besonders gefreut habe ich mich über Corn🌽Gosumi🦔, einen alten Bekannten. Seine Node war vor einiger Zeit komplett offline gegangen, weshalb er alle Kanäle schließen und neu aufsetzen musste. Schade damals, denn er war ein hervorragender Kanalpartner. Umso schöner, dass er wieder da ist.

Außerdem öffnet Sunny Sarah , eine der größeren und aktivsten Nodes mit hohem Lightning-Terminal-Rang, spontan einen 10M-Sats-Kanal zu mir. Auch ArthurReilly öffnet seinen Swap-Kanal.
Am Samstag folgen schließlich die letzten Kanalöffnungen der Woche – vier Pool-Kanäle und einer zu WCC-Bouncer, einer großen Node mit sehr sauberem Gebührenmanagement (zumindest soweit ich das beurteilen kann).

Damit stehen nur noch wenige Pool-Anfragen sowie ein eingehender Swap-Kanal aus.
Den gesamten Bitcoin konnte ich diese Woche zwar noch nicht vollständig in neue Kanäle umwandeln – zumindest nicht, wenn ich dabei auch auf Gegenseitigkeit (Kanäle oder LN+ Credits) setze. Ich überlege, ob ich den Rest einfach für direkte Kanäle zu größeren Nodes nutze, verschiebe die Entscheidung aber auf nächste Woche.

Gebührenstrategie & charge.config-Überarbeitung

Gegen Ende der Woche kümmere ich mich wieder um mein Gebührenmanagement.
Die bisherigen Erfahrungen mit positiven eingehenden Gebühren zeigen, dass sie prinzipiell funktionieren – aber viele Nodes im Netzwerk nicht richtig damit umgehen können. Dadurch schlagen manche Weiterleitungen wegen zu geringer Gebühren fehl.

Ich entscheide mich daher, zurück zu meiner älteren Strategie der „effektiv positiven eingehenden Gebühren“ zu wechseln, die ich schon früher erfolgreich getestet hatte.
Bevor ich das umsetze, möchte ich jedoch meine mittlerweile recht unübersichtliche charge.config-Datei überarbeiten.

Ich experimentiere etwas herum und schaffe es schließlich, den Inhalt der Datei in mehrere kleinere Konfigurationsdateien auszulagern.
Von der Hauptdatei aus kann ich nun auf einzelne configs verweisen – etwa für Sources, Sinks, oder spezielle Strategien.
Das macht das Ganze deutlich übersichtlicher und flexibler.
Nächste Woche werde ich daran weiterarbeiten, bevor ich dann endgültig auf die „effektiven positiven eingehenden Gebühren“ umstelle.

Fazit Woche 17

Nach dem holprigen Start mit dem Bitcoin-Core-Absturz läuft die Node wieder stabil und performt spürbar besser.
Die neu angelegte Swap-Datei scheint ihr Ziel zu erfüllen, und auch im Lightning-Netzwerk geht es endlich wieder voran – mit vielen neuen Kanälen und einigen alten Bekannten, die zurückgekehrt sind.
Ich bin gespannt, wie sich die neuen Verbindungen und das angepasste Gebührenmanagement in den nächsten Wochen auf Routing und Einnahmen auswirken werden.

Die Gesamtkapazität der Node am Ende der Woche beträgt ca. 3,21 BTC in 88 Kanälen.

Astrea · 3. November 2025 um 20:08

Woche 18 – Mysteriöse Geschehnisse im Lightning-Netzwerk, starkes Wachstum und der Riesen-Kanal

Es passieren seltsame Dinge im Lightning-Netzwerk. Dinge, die ich mir nicht erklären kann. Dinge, die keinen Sinn ergeben – und doch passieren sie. Diese Woche stoße ich auf eine Entdeckung, die mein bisheriges Verständnis von Lightning zumindest ins Wanken bringt.

Doch der Reihe nach: Die Woche beginnt ruhig. Einige meiner LN+ Pool-Anfragen werden angenommen, und ich eröffne Kanäle zu SovereignSats (3M Sats), Bit2Cash (3M Sats) und MOLA (10M Sats). Zusätzlich kommt ein unangefragter Kanal hinzu – 10 Millionen Sats zu Kazumyon, einer Top-Node (Rang 23 auf Lightning Terminal) mit gutem Gebührenmanagement und vielen frischen Verbindungen. Das ist mir den Einsatz wert, auch ohne einen Rückkanal zu bekommen.

Am Donnerstag fällt mir dann eine riesige Weiterleitung auf:

9 Millionen Sats in einer einzigen Transaktion von „Kraken“ zu „Bee Tee See“.

Das ist nicht nur die größte Weiterleitung, seit ich meine Node betreibe, sondern sie verläuft auch von einer Sink-Node zu einer Source-Node – also perfekt. Die 9 Millionen Sats, die dadurch im Kraken-Kanal landen, kann ich für rund 1000 ppm wieder zurückleiten. Unterm Strich etwa 9000 Sats Gewinn in einem einzigen Hop – fantastisch! Ich überlege, den Kraken-Kanal zu vergrößern, um künftig mehr solcher Transaktionen aufnehmen zu können.

Kurz darauf häufen sich jedoch ungewöhnliche Beobachtungen: Über den Kanal c-otto.de laufen plötzlich viele Transaktionen in kurzer Zeit, und das Rebalancing gelingt auf einmal mühelos – auch mit größeren Beträgen. Dasselbe sehe ich bei Kraken und fortuna-custody-stroom: hohe Erfolgsraten, wo sonst oft mehrere Versuche nötig sind. Solche Änderungen deuten normalerweise auf neue Routen im Netzwerk hin, aber die Dimension ist ungewöhnlich.

Ich sehe mir c-otto.de genauer an – und werde fündig:
Die Node 03d1739dcb86ce7a48d1 hat eine ganze Reihe von Kanälen zu c-otto.de eröffnet. Alle um die 16 Millionen Sats, alle erst wenige Stunden alt. Ein Blick in die kürzlich geschlossenen Kanäle zeigt das gleiche Muster: Zahlreiche Verbindungen zu dieser Node, geöffnet und nach kurzer Zeit wieder geschlossen.

Weitere Recherchen zeigen: Dasselbe passiert mit den Nodes okx und cyberdyne.sh. Auch hier öffnet 03d1739dcb86ce7a48d1 mehrfach 16M-Kanäle, schließt sie nach kurzer Zeit und eröffnet neue. In den geschlossene Kanälen taucht außerdem eine weitere Node auf: 02c26abcde33d76c5a85, die dasselbe Muster zeigt, allerdings seit dem 27. Oktober inaktiv ist. Ich gehe davon aus, dass beide von derselben Entität kontrolliert werden.

Hier die Kanal-Historie von c-otto.de:

Aber warum?
Die naheliegende Erklärung: Jemand wollte größere Beträge per Lightning verschicken und hat dafür Kanäle geöffnet – eventuell mit einer Software, die keine Wumbo-Kanäle unterstützt (also keine Kanäle über ~16M Sats). Aber selbst dann bleibt die Frage: Warum über Lightning, wenn On-Chain-Transaktionen dafür billiger wären? Das Ganze ergibt wirtschaftlich keinen Sinn.

Für mich relevant ist vor allem die Folge: c-otto.de erhält durch dieses Verhalten temporär viel Inbound-Liquidität, was Rebalancing für mich günstiger macht. Gleichzeitig laufen aber auch ausgehende Transaktionen über diesen Kanal plötzlich besser – obwohl ich die Gebühren dort sogar erhöht habe. Je mehr ich analysiere, desto mehr widersprechen sich meine Erklärungen.

Das Phänomen hält über mehrere Tage an. Immer wieder werden neue 16M-Kanäle zwischen 03d1739dcb86ce7a48d1 und den drei betroffenen Nodes geöffnet und kurz darauf wieder geschlossen.

Währenddessen bleibt der Kraken-Kanal weitgehend ungenutzt. Ich vermute, dass die Umverteilung der Liquidität im Netzwerk etwas damit zu tun hat. Kurz überlege ich, die Gebühren zu senken, lasse es aber bleiben – vermutlich normalisiert sich das von selbst.

Stattdessen fasse ich einen anderen Plan:
Ich habe noch rund 25 Millionen Sats für offene Pool-Anfragen zurückgelegt. Warum also nicht den fast vollen Kraken-Kanal schließen und durch einen größeren ersetzen? Ich teste zuerst eine kleine Lightning-Einzahlung bei Kraken – funktioniert problemlos. Also schließe ich den alten 10M-Kanal und eröffne stattdessen einen neuen, gigantischen 35M-Sats-Kanal zu Kraken.

Nach dem Öffnen des neuen Kanals sende ich zunächst eine größere Einzahlung über Lightning an mein Kraken-Konto. So landet die Liquidität, die zuvor lokal war, jetzt auf der Gegenseite des Kanals – also als Inbound-Liquidität für mich. Geplant ist, diese Sats später wieder on-chain auszuzahlen, um meine ursprünglichen Mittel für die Pool-Anfragen zurückzuerhalten. Die Transaktion selbst läuft reibungslos, und ich kann direkt sehen, wie sich die Liquidität im Kanal wie vorgesehen verschiebt. Wäre ich da nur früher drauf gekommen - als ich noch den ganzen Bitcoin für neue Kanäle zur Verfügung hatte.

Damit habe ich nun genauso viel Outbound-Liquidität wie zuvor, aber zusätzlich rund 25 Millionen Sats Inbound. Perfekt! Und tatsächlich: Im Verlauf der Woche laufen über den neuen Kanal etliche erfolgreiche Rebalancings und ungewöhnlich viele eingehende Transaktionen von Kraken. Am Wochenende steht der Kraken-Kanal bei rund 20M Outbound, und ich hoffe, bald wieder aktiv in Richtung Kraken weiterleiten zu können – mit entsprechenden Gebühreneinnahmen.

Beim Gebührenmanagement selbst komme ich diese Woche weniger voran. Ich beschäftige mich etwas mit torq, einer vielversprechenden Software für Node-Management mit sehr umfangreichen Funktionen – allerdings ohne Unterstützung für positive eingehende Gebühren. Der Einstieg fällt mir noch schwer, aber ich bin überzeugt, dass torq langfristig charge-lnd und LNDg übertreffen kann. Ich bleibe dran.

Fazit

Eine Woche voller Rätsel. Ich habe viel beobachtet, experimentiert und gelernt – vor allem, dass sich das Lightning-Netzwerk manchmal kaum logisch erklären lässt. Der neue Kraken-Kanal markiert einen wichtigen Meilenstein für meine Node. Gleichzeitig bleibt das Verhalten der Nodes 03d1739dcb86ce7a48d1 und 02c26abcde33d76c5a85 ein Rätsel. Vielleicht klärt sich das irgendwann, vielleicht auch nicht – spannend ist es allemal.

Was denkt ihre darüber?

Die Gesamtkapazität meiner Node am Ende der Woche beträgt ca. 3,8 BTC in 94 Kanälen.

Primexz · 3. November 2025 um 20:56

Spannende Beobachtungen, wie immer ein schöner Einblick in deine Node. ;)

Bzgl. torq, das Tool sieht erstmal spannend aus, ist aber anscheinend nicht Open Source. Ich bin bei sowas immer eher vorsichtig.. Schließlich vertraut man dem Unternehmen/Tool indirekt alle seine Sats an. Soll nicht heißen, dass da irgendwas passieren muss, hat aber immer einen faden Beigeschmack.

Libre · 3. November 2025 um 23:08

Hallo Astrea,

Sorry für den Off-Topic, aber könntest Du vielleicht etwas näher auf dein Out of Memory-Error eingehen und wie Du das mit der Swap Datei gemacht hast? Wusste gar nicht dass man Ram Speicher auch swappen kann.

Ich glaube nämlich dass ich ein ähnliches Problem habe, die Node friert gelegentlich ein und ich denke auch dass es an der Core App liegt, da diese im normalen Betrieb manchmal bis zu 10 GB Ram nutzt. Ich bemerke das dann immer erst wenn die Miner auf einmal auf einem anderen Pool laufen.

An meinem System sollte es eigentlich nicht liegen, da es für eine Node recht überdimensioniert ist und 32 GB Ram sollten eigentlich auch reichen..

So lange das Problem bestehen bleibt werde ich keine Lightning Kanäle mehr öffnen, hatte durch so ein Freeze mal das komplette System neu installieren müssen, danach hatte ich keinen Zugriff mehr auf die Kanäle.

Hoffe dass es mit dem neuen OS 1.5 eventuell besser wird (neuer Linux Kernel enthalten)

Ansonsten mach bitte weiter so mit deinem Tagebuch, ist echt spannend zu lesen!

Astrea · 4. November 2025 um 06:46

Swap ist meines Wissens immer virtualler RAM. Du kannst schauen ob du bereits eine aktive Swap-Datei hast mit:

free -h

Bei mir wurde da nur mein RAM und kein Swap angezeigt. Meine Node läuft mit Umbrel auf meinem Raspberri Pi 5. Da habe ich die Swap-Datei erstellt und aktiviert wie folgt:

sudo dd if=/dev/zero of=/run/rugpi/mounts/data/swapfile bs=1M count=4096 status=progress
sudo chmod 600 /run/rugpi/mounts/data/swapfile
sudo mkswap /run/rugpi/mounts/data/swapfile
sudo swapon /run/rugpi/mounts/data/swapfile

Damit wird eine 4GB Swap-Datei erstellt und aktiviert. Ob es geklappt hat kannst du testen mit:

free -h

Dort sollte nun neben dem verfügbaren RAM auch der verfügbare Swap angezeigt werden. Falls du aber schon eine Swap-Datei hast und diese vergrößern willst solltest du sie erste deaktivierten und löschen, dann eine neue, größere erstellen.

Astrea · 9. November 2025 um 20:15

Woche 19 – Netzwerkanomalien, Wachstum und Experimente am Limit

Die mysteriösen Geschehnisse im Lightning-Netzwerk gehen weiter – und nicht nur das: Sie breiten sich aus und scheinen das Netzwerk zunehmend zu verzerren.

Doch bevor wir dazu kommen, startet die Woche gleich am Montag stark: Fünf neue Kanäle mit insgesamt 37 Millionen Sats. Ich öffne Kanäle zu:

kappa – 10 M Sats
1sats.com⚡️lsp.flashsats.xyz – 10 M Sats
None – 10 M Sats
i’llTryAnythingOnce – 5 M Sats
Unchained Satoshis – 2 M Sats

Die ersten beiden eröffne ich ohne Rückkanal oder Credits – es sind große, gut vernetzte Nodes, die sich langfristig lohnen dürften. Die anderen drei stammen aus LN+ Pool-Anfragen, also gibt es dafür Credits, die künftig neue eingehende Kanäle ermöglichen.
Damit summieren sich meine aktiven und ausstehenden Credits auf rund 70 M Sats. Für die nächsten Wochen verspreche ich mir davon einige eingehende Verbindungen. LN+ Pool lasse ich vorerst ruhen – ich habe genug Credits gesammelt und bin mit den wichtigsten Nodes bereits verbunden. Stattdessen konzentriere ich mich jetzt auf hochrangige Nodes mit gutem Lightning-Terminal-Score und sauberem Gebührenmanagement.

Einen kleinen Dämpfer gibt es aber auch: Skyweir war tagelang offline, wodurch meine Node den Kanal zwangsgeschlossen hat. Eigentlich wollte ich ihn offen lassen, aber offenbar waren noch HTLCs aktiv – also musste der Close aus Sicherheitsgründen erfolgen.
Zunächst bekomme ich nur einen Teil der Sats zurück, obwohl der Großteil auf meiner Seite lag. Kurz darauf kommt der Rest in einer separaten Transaktion an – alles gut. Interessant ist aber, dass sich HTLC-Abwicklung und Kanal-Close in getrennten On-Chain-Transaktionen zeigen – das war mir so noch nicht begegnet.
Kurz danach meldet sich Skyweir, entschuldigt sich und öffnet den Kanal am Sonntagabend wieder.

Währenddessen beobachte ich weiter die mysteriösen Nodes aus der letzten Woche – und das Muster setzt sich fort:

03d1739dcb86ce7a48d1 ist weiterhin aktiv und öffnet 16 M-Sats-Kanäle, vor allem zu okx und c-otto.de.
02c26abcde33d76c5a85 bleibt inaktiv.
Neu ist 03d6c33746ea3222f5fc, die exakt das gleiche Verhalten zeigt: Kanäle mit rund 16 M Sats, die nach wenigen Stunden wieder geschlossen werden.

Zwischendurch tauchen auch Kanäle zu anderen Nodes auf – etwa 1sats.com⚡️lsp.flashsats.xyz oder ACINQ – verschwinden aber wieder, da Amboss nur die letzten 100 Schließungen zeigt. Am Ende bleibt: okx und c-otto.de sind offenbar die bevorzugten Partner.

Zwischendurch steigt die Kapazität von c-otto.de auf über 61 BTC, fällt kurz darauf wieder auf etwa 40 BTC. Vor wenigen Wochen lag sie noch unter 30 BTC. Besonders auffällig: Zwischen c-otto.de und okx entstehen zahlreiche neue, teils riesige Kanäle mit 2–3 BTC pro Verbindung. Insgesamt kommen allein diese Woche über 16 BTC hinzu.
Ich vermute, der Betreiber der mysteriösen Nodes verschiebt gezielt Liquidität zu diesen großen Hubs. Aber warum nicht direkt zu den Zielnodes verbinden? Vielleicht gibt es technische Limits für neue Kanäle oder schlicht interne Restriktionen.

Dann stoße ich auf zwei ältere Hex-Nodes: ed528ad49bedd1f7a638a und e960fd8385a1603003727, beide seit über drei Jahren aktiv, mit nur 20 Stunden Altersunterschied. Diese Woche schließen sie zahlreiche große Kanäle zu cyberdyne.sh, ACINQ und block – zusammen über 49 BTC.
Von den mysteriösen Nodes ist dabei nichts zu sehen – bis mir eine Idee kommt :
Was, wenn diese Verbindungen über private Kanäle laufen?
Das würde erklären, warum sie in Amboss nicht sichtbar sind und warum so viele öffentliche Kanäle geschlossen werden – die Liquidität könnte über private Verbindungen umgeschichtet worden sein. Immer wahrscheinlicher scheint, dass alle diese Nodes zur selben Entität gehören. Ich bleibe dran.

Beim Gebührenmanagement schieße ich diese Woche etwas übers Ziel hinaus. Ich will zu viel auf einmal. Anfang der Woche stelle ich ein Google Sheet fertig, das mir automatisch charge-lnd-Konfigurationen erstellt. Hintergrund: Outbound-Fees lassen sich in charge-lnd proportional zur Liquidität steuern, inbound aber nicht. Mein Sheet löst das – ich definiere für jeden 0,1 %-Schritt in der Kanalverteilung eine eigene Regel.
Ergebnis: Rund 7000 Zeilen pro Strategie – eine für „Sources“, eine für „Heavy Sources“ und eine für „Standard Nodes“. Die Sinks folgen später.

Dann experimentiere ich erneut mit den effektiven positiven eingehenden Gebühren. Doch kaum umgestellt, brechen die Weiterleitungen ein. Also wieder zurück zu echten positiven eingehenden Gebühren – aber auch da bleibt das Volumen schwach. Liegt’s am Netzwerk oder an meinem ständigen Strategiewechsel? Vielleicht beides.

Nebenbei arbeite ich mich tief in torq ein – eine mächtige Node-Management-Software, die langfristig charge-lnd und LNDg ersetzen könnte. Leider stoße ich auf mehrere Bugs, vor allem beim Rebalancing. Auch die Umbrel-Version ist veraltet, und der Support bestätigt die Probleme. Mein Fazit: torq ist vielversprechend, aber noch nicht reif für den produktiven Einsatz. Ich werde spätere Versionen auf jeden Fall wieder testen.

Und so sieht das ganze aus:

Am Ende der Woche fühle ich mich ehrlich gesagt etwas ausgebrannt. Zu viel Gebührenschrauberei, zu viele Tests und Anpassungen auf einmal – da bleibt anderes schnell liegen.
Ich beschließe, kommende Woche etwas kürzer zu treten und mir in Ruhe eine neue Herangehensweise fürs Gebührenmanagement zu überlegen. Eine Idee habe ich schon – aber die braucht Zeit, um richtig durchdacht zu werden.

Fazit Woche 19

Eine Woche voller Rätsel und neuer Erkenntnisse. Das Netzwerk scheint sich zu verändern – und ich bin mittendrin. Viele neue Kanäle, Experimente mit Gebührenstrategien und spannende Beobachtungen rund um das mysteriöse Node-Netzwerk.

Gesamtkapazität am Ende der Woche: ca. 4,17 BTC in 99 Kanälen.

Primexz · 10. November 2025 um 10:36

Ich habe auch den Force-Close mit Skyweir hinter mir.

Besonders spannend sind die Gebühren vom Force-Close. Ich hatte ebenfalls offene HTLCs, wodurch zusätzliche On-Chain-Transaktionen nötig waren.

Insgesamt ~1.1k Sats für den Force-Close. :/

Banker · 14. November 2025 um 08:52

Die Hex-Nodes gehören vermutlich zu Lightspark - evt. sind es die Coinbase Nodes, die ja Lightspark nutzen.