Lightning Kanäle laufen leer

Genau, automatisieren würde ich am Anfang überhaupt nichts. Da ist es viel wichtiger die Dynamik zu lernen und eine eigene Strategie zu finden. Etwas anderes ist es, wenn man mit c-lightning clboss verwendet, aber die meisten sind hier ja auf lnd. Da kann man derzeit nur die erwähnten Skripts nutzen und selbst Wrapper drumherum bauen.

2 „Gefällt mir“

So habe ich das auch nicht geschrieben… :roll_eyes:

Mein Argument bezog sie auf die Zukunft des Lightning-Netzwerks:

  • Um eine wirklich profitable Node zu haben (und ich spreche hier von sagen wir 2-3% Rendite p.a. auf das eingesetzte Kapital), benötigt mal viel Kapital (sagen wir mal ab 2-3 BTC, besser mehr)
  • Zum heutigen Kurs sind das also rund 100.000 EUR. Ich würde 100.000 EUR nicht zuhause in einem Schrank aufbewahren sondern in einem feuerfesten Safe + Alarmanlage im Haus oder eben in einem Bank-Safe.
  • In Analogie ist das ein kleiner Heim-Server mit USV + RAID oder eben ein angemieteter Server in einem Rechenzentrum.

Aber ich glaube wir kommen etwas von der ursprünglichen Frage ab. Vielleicht mach ich mal einen Thread auf zum Thema „Zukunft Lightning“ oder so…

2 „Gefällt mir“

Ich meinte egal mit welchem der beiden Skripte, über die wir gesprochen haben. Wie gesagt ist die Konfig dort mit hinterlegt - denn offensichtlich klappt es manuell ja nicht.

Wenn es Dir nur um die Unterstützung geht und du keine Rebalancing-Kosten haben möchtest, könntest du auch versuchen, alle Fees auf 0 zu stellen und kein Rebalancing zu betreiben (wie „zero fee routing“). So wird deine Node als kostenlose Weiterleitung an deine Peers gesehen, ggf. auch mal kurzzeitig für ein paar Stunden (penalty in LND’s mission control) abgestraft, weil die Liquidität nicht gerade da liegt, wo sie gebraucht wird.

Kein Verlust (Routing), kein Gewinn, aber Unterstützung des Netzwerk (der angebundenen Nodes).

Bedenke aber, dass du auf jedenfall Kosten hast für:

  • das Öffnen und Schließen von Kanälen
  • evtl. Force Closes durch LND Bugs oder länger feststeckende HTLCs (Forwards), die bei vollem mempool sehr teuer werden können.
2 „Gefällt mir“

Ich verstehe deinen Vorschlag, aber genau diese „zero fee nodes“ sind doch letztlich das Problem wenn es um das wirtschaftliche Betreiben des Netzwerkes geht. Deshalb wollte ich meinen node als „Null-Summen-Spiel“ konfigurieren.

Fees nur so hoch, um das Rebalancing zu finanzieren, damit ich nicht drauflege, aber keine Gewinnabsicht, um das noch wachsende Netzwerk bestmöglich zu unterstützen.

Auch die Thematik der Sicherheit eines Raspis ohne Redundanz, ohne USV ist für mich ein Thema. Ich habe mir Anfangs sehr gut überlegt, wie viel Kapital ich über einen Raspi zur Verfügung stellen will, vor allem auch mit dem Hintergedanken, dass die langjährige Kursentwicklung zumindest noch 1 Null vor dem Komma platzieren wird.

Denn selbst wenn ich bereit wäre 3 ganze BTC ins Lightning Netz zu stellen (was nicht möglich ist, da ich nicht so viele habe) … so wäre das heute der Gegenwert eines gehobenen PKWs, und war vor wenigen Monaten noch ein kleines Haus auf dem Land … und wenn da in den kommenden 10 Jahren nur alle 4 Jahre ein 2x ansteht (SEHR KONSERVATIV) … dann entspräche das in 10 Jahren dem Gegenwert von ca. 33 Jahre Medianbruttoeinkommen für Normalsterbliche (also mehr als dem Gesamtverdienst eines halben Erwerbslebens) … Österreich - Bruttojahreseinkommen 2020 | Statista

UND SOLCHE WERTE STELLE ICH ALS PRIVATPERSON NICHT ohne Ausfallsicherung oder ohne USV oder ohne RAID5 zur Verfügung… sprich dazu braucht es proffessionelle Dienstleister, was im Ergebnis das Gegenteil von Dezentral ist.

Abgesehen davon, dass ich niemals bereit wäre 100% meiner BTC ins Lightning zu stellen. Ergo, was bleibt einer wie mir da übrig?

Ich werd die Flinte noch nicht ins Korn werfen, vielleicht schaff ich ja meine Null-Summen-Konfiguration doch noch, und falls nicht, … weiß ich noch nicht.
Ich seh da auf jeden Fall eine rießige Herausforderung für das gesamte Lightning Netzwerk.

P.s.:
Bin weiblich - und hab mich an beiden skripts probiert … bin dann aber wieder einen Schritt zurück auf manuelle Konfiguration mittels RTL und Thunderhub, da ich für mich selbst festgestellt hab, dass mir noch Lernprozess zum konfigurieren der skripts fehlte.

Ich helfe Dir gern dabei, es nochmal zu probieren, schreib mich einfach an. Auch mit einem Watchtower kannst du vielleicht etwas mehr gefühlte Sicherheit ins Spiel bringen, auch das ist kein Hexenwerk :X

1 „Gefällt mir“

Es ist sicherlich schwieriger mit einer kleinen Node kostenneutral zu werden als mit einer großen. Aber irgendwie muss man ja erstmal klein Anfangen um das Handling einer Node zu verstehen. Daher sehe ich den Einstiegsprozess als Lernphase in der auch ein paar Sats als Lehrgeld (Reballancing Fees) verloren gehen. Bis ca. 50 Channels ist ein Raspi ganz gut in der Lage als Node zu fungieren, ab da wird es dann etwas zäh. Beim Thema USV, Raid usw. muss man gar nicht sooo groß denken. Ein 2bay NAS das Virtualisierung kann, 2 SSDs und eine kleine USV ist für einen dreistelligen Betrag zu bekommen und kann dann deutlich mehr als nur eine Node bereitzustellen. Ich betreibe nun seit 1,5 Jahren Nodes und erst seit ein paar Monaten läuft die Hauptnode kostenneutral (bzw. leicht im +) .
Das die Node anfangs nicht redundant ausgelegt ist halte ich für gar nicht so schlimm. Wichtig ist allerdings zu verstehen wie man die Node nach einem Totalausfall wieder zum Laufen bekommt.
BTW, von Channels die einen zu großen Druck in eine Richtung haben trenne ich mich auch immer wieder mal. Es bringt nichts sich diesem Zustand mit Fees entgegenzustellen.

4 „Gefällt mir“

Noch eine Anmerkung zu deinen Gebühren, wenn Du erlaubst: 5 Sat base fee sind sehr viel und schrecken vermutlich kleinere Zahlungen zusätzlich ab. Würde hier eher über höhere fee rates agieren und die base fee auf 0 oder < 1 belassen. Und das Timelock Delta scheint mir mit 100 auch außerhalb des Standards (40) zu sein.

1 „Gefällt mir“

Ich habe überall basefee 0 und hauptsächlich kleine Transaktionen, meist so zwischen 100-10.000. Das hat für kleinere Kanäle auch den Vorteil, dass man früher merkt, wenn ein Rebalancing möglich ist.

Es ist irgendwie deprimierend, wenn man am Anfang seinen Kanal teuer rebalanced hat und dann wird er mit einer großen Transaktion leergezogen – bevor man überhaupt realisiert, dass die eingestellten Gebühren viel zu niedrig waren!

Deswegen mein Tipp: Basefee auf 0, und ev. sogar einen „Max HTLC“ auf einen niedrigeren Wert einstellen. Standardmäßig wird da die Kanalgröße genommen, aber man kann ja bspw. mit 1/10 der Kanalgröße beginnen. Dann kann man langsam ein Gefühl für die wirtschaftlichen Gebühren bekommen.

2 „Gefällt mir“

Ich hole mal dieses Thema nochmal hoch, da ich vor einem ähnlichen Problem stehe.

Bei mir werden die Kanäle leer gezogen direkt nach der Öffnung des Kanals. Da die Öffnung eine gewisse Zeit benötigt bin ich oftmals nicht online um die Standarteinstellung rechtzeitig umzustellen. Es ist sehr frustrierend wenn innerhalb von einer Stunde alle Sats gezogen wurden und man diese teuer rebalancen muss. Kann man die Standard Einstellungen nicht ändern? Danke

klar kannst Du das ändern: Einfach den Parameter in der lnd.conf ändern:

[Bitcoin]
bitcoin.feerate=2500

Neustart von lnd ist dann erforderlich.

2 „Gefällt mir“

puuhhh, sorry. bin absoluter noob:
Wieso muss man rebalancen^^
wann muss man rebalancen?
wo gibt es Skripte zum automatisiterten umbrel rebalance?
wie verwendet man die APPS RTL | Thunderhub? Also auf welche signifikanten Werte muss man da am meisten achten?
Gibt es da ein Guide/Tutorial?

Wünschte, würde auch ein Gefühl für das ganze Thema entwickeln…

Es gibt hier einige sehr gute Beiträge aus der Community wie z.B. Lightning - Erfahrungen [Liquidität, Gebühren]

Müssen tust du nix, alles ist freiwillig. Wenn du die Node für einen Shop betreibst, interessiert dich vorrangig Inbound Liquidität. Willst du deine Einkäufe per Lightning bezahlen, interessiert dich vorrangig nur deine Outbound Liquidität. Erst wenn du eine Rounting-Node betreiben willst kommt das Thema rebalancen überhaupt auf den Tisch. Optimal sind große 50/50 ausbalancierte Channels, die Sats können dann in beide Richtungen beliebig über deine Node „fließen“. Alles was von diesem Optimum abweicht verringert deine Routingfähigkeiten. Ein guter Richtwert ist wenigstens 1M Liquidität sowohl Inbound als auch Outbound im Channel zu haben. Das zeigt auch gleich das 2M Channels im Grunde schon zu klein sind (ich verabschiede mich auch langsam von dieser Größe).

Du kannst dir mal LNDg anschauen, gibts unter den Apps auf Umbrel. Und hier nen Einführungsvideo dazu.
Ansonsten geht auch ne Menge über die Lightning Shell (ebenfalls unter Apps), die hat diverse Tools dabei um eher manuell die Channels zu rebalancen.

Ist Geschmackssache wie man das ganze visualisiert haben will. Entscheidend sind ja eher die Grundlagen die man erstmal verstehen muss und dann kann man z.B. alles über LNDg machen oder auch Thunderhub, RTL, LNtop, usw. alles parallel verwenden.

fee-rate, base fee, fees für Onchain-Transaktionen beim öffnen und schließen von Channels. Es bringt nicht so viel hier jetzt irgendwelche Werte zu schreiben. Du musst wissen was die Werte bewirken und dann hast du auch nen gutes Gefühl dabei da was sinnvolles einzustellen.