Experiment mit Lightning Routing-Gebühren
Experiment mit Lightning Routing-Gebühren
Jeden Monat verschiedene Gebührenrichtlinien festlegen und das Routing der LN-Knoten beobachten
Vorwort
Meine ersten Berührungspunkte mit Nodes hatte ich im Jahr 2019 mit einem einfachen C-Lightning-Knoten. Es lief gut an, ich lernte viel über das Lightning Netzwerk im Allgemeinen und wie man einen BTC/LN-Knoten betreibt, welche Vorteile und welche Unannehmlichkeiten es geben kann.
Im Jahr 2020 habe ich dann Umbrel entdeckt. Also habe ich meinen C-Lightning-Knoten gegen einen neuen Umbrel-Knoten ausgetauscht. Ich habe jetzt einen Gigabyte Brix NUC mit Debian OS.
Nur um mehr zu lernen und auch um den vielen neuen Nutzern zu helfen, die mit der Installation von Umbrel starteten, aber keine Ahnung hatten, was Lightning (LN) und eine Node eigentlich ist.
Der beste Weg war es also zu testen, zu lernen, wie man eine Node benutzt, zu entdecken und dann langsam alle meine Schritte in einfachen Anleitungen zu dokumentieren. Ich habe so meine Lernkurve mit neuen Nutzern teilen können, die nach diesen Informationen suchten und "How to"-Tutorials dringend benötigten.
So baute ich auch diesen Knoten langsam aus öffnete Kanäle, studierte die Peers genau und erstellte eine Liste guter Peers (die auch die berühmte René Pickhardt-Liste der ZeroBaseFee-Knoten enthält).
Ich behaupte nicht, dass mein Vorgehen, Richtlinien und Ansätze perfekt sind. Es sind nur meine Beobachtungen und meine eigenen Schlussfolgerungen darüber, wie man einen LN-Knoten verwaltet. Ich bin weder ein Experte noch ein LN-Coder oder ein "Guru", sondern nur ein einfacher Beobachter, der mit seinem gesunden Menschenverstand alles beobachtet, was mit seinem Knoten passiert.
OK, ich bin also einigen Rings of Fire beigetreten - LN+ Ringen, privaten Gruppen usw. und habe mich auch mit einigen grösseren Nodes verbunden in den 2 Jahren seit dem Start mit Umbrel. Bis ich eine Grenze von 40 Channels und gute stabile Channels und Peers erreicht hatte. Mit vielen halte ich direkten Kontakt. Es ist gut, sich gegenseitig zu helfen (vielleicht werde ich über das Plebs together strong Konzept noch einen weiteren Leitfaden erstellen).
Dann, im Jahr 2022, starte ich eine zweite Node, einen privaten Knoten, ohne Alias, nur Tor, in keiner Weise mit meiner echten Identität oder einer anderen Online-Identität verbunden. Dies ist Teil eines weiteren Experiments, auf das ich weiter unten im Text auch nochmal eingehen werde.
Ich bin NICHT daran interessiert, "Geld" oder "Gewinne" aus dem Betrieb der Node zu machen. Mein Ziel ist es, LN zu einem sehr liquiden Zahlungsnetzwerk zu machen, so dass die Nutzer es Tag für Tag nutzen und aufhören, das verdammte Fiat zu verwenden. Wir werden k ein gesundes Zahlungsnetzwerk bekommen, wenn wir anfangen, uns gegenseitig auszurauben und versuchen, das Netzwerk nur für ein paar miserable Sats zu mißbrauchen.
Wenn das LN wirklich stabil ist, mit wirklich gutem Pathfinding und gesunden gut eingebundenen Nodes, dann können es viele Nutzer als tägliche Basis für Zahlungen nutzen (nicht nur dummes Re-Balancing). Und erst dann sollten wir über eine Erhöhung der Gebühren reden und langsam ein Anreizmodell für Routing-Knoten aufbauen.
Wir sind noch NICHT am Ziel, egal was andere dir erzählen, wie sie eine x-fache Menge an Sats/Monat verdient haben. EINFACHE USER WERDEN ES NICHT SCHAFFEN!
Und denkt daran: Das Ziel ist es, die Banken zu ficken, nicht uns (Bitcoiner) gegenseitig ...
Wenn wir jetzt anfangen, teure Gebühren von neuen Nutzern zu verlangen, die LN nutzen wollen mit winzigen Kanälen, dann werden sie Angst bekommen und abhauen, werden sagen, dass dieses LN ein scheiß teures Zahlungssystem ist und nicht funktionieren kann.
Lasst uns die Neuen nicht verschrecken, sondern ihnen dabei helfen, diese erstaunliche Technologie zu nutzen. Wir werden später viel Zeit haben, um die Gebühren auf ein Niveau anzuheben, das einen Anreiz darstellt.
GIER TÖTET INNOVATIONEN.
Wie alles begann... #ZeroFeeFebruary
Im Februar 2022 startete ich mit einem meiner Kollegen eine Bewegung #ZeroFeeFebruary mit vielen Rings of Fire und Gruppen. Es lief ziemlich gut mit 35+ Nodes, die ihre Kräfte bündelten und alle Kanalgebühren auf 0/0 setzten (0 Grundgebühr, 0 ppm).
Mein bescheidener Umbrel-Knoten begann, die Anzahl der durchgeleiteten Zahlungen zu verdoppeln, zu verdreifachen, zu vervierfachen. Ich habe auch einige kleine Zombie-Channels mit Peers geschlossen, die in den letzten 6 Monaten überhaupt nicht angewachsen sind.
Dies ist ein sehr wichtiger Aspekt: Peers, die in den letzten Monaten nicht genug gewachsen sind, sind NUTZLOS und können mehr schaden als nutzen.
Also eine Warnung an alle Noobs mit neuen Nodes: Wenn du planst, einen LN mit nur 2-3 Channels zu betreiben und nie mehr zu wachsen, rechne damit, dass deine Peers die Channels schließen werden. Stapelt mehr Sats und öffnet größere LN-Kanäle statt viele. Gelder in LN sind nicht "verloren" oder "blockiert". Sats in LN-Kanälen SIND FUCKING LIQUIDITY. Das bedeutet, dass sie fließen MÜSSEN. Sonst sind sie dort völlig nutzlos.
Also begann ich ebenfalls, die Kanäle mit Gleichgesinnten zu schließen, die hohe Gebühren verlangten. Hohe Gebühren sind für mich:
Grundgebühr >1 | alles was darüber liegt ist dumm und schadet mehr als es nützt
ppm >150-200 | manchmal ist das ppm notwendig, um die Liquidität auf die eine oder andere Seite zu schieben, wenn man es wirklich braucht, z.B. bei Händlern, die nicht auscashen wollen, sondern nur den Traffic zum Ausgleichen der eigenen Liquidität zulassen.
Wenn also ein Peer, der mit meinem Node verbunden ist, für alle seine Channels eine Standard-Policy wie 2 sats Grundgebühr / 300 ppm verwendet, schließe ich den Channel - ohne Reue. Oder ich setze die Grundgebühr so hoch, dass der gesamte Verkehr auf diesem Kanal blockiert wird, bis er ihn selbst schließt.
Auch diejenigen, die das Skript charge-lnd intensiv nutzen. Bitte hört auf es zu benutzen, wenn ihr ein Noob seid! Oder lernt wenigstens, was ihr damit zu tun habt und wie es funktioniert.
Es richtet mehr Schaden als Nutzen an. Das Skript ist so konzipiert, dass es Kanäle ab einem bestimmten Grad der "Rentabilität" automatisch abschaltet. Der Benutzer weiß nicht einmal, dass seine Kanäle deaktiviert werden, und das bedeutet "verschlossene Türen". Das bedeutet, dass Traffic in keiner Weise mehr durch diese Kanäle geleitet wird. Wenn ich also einen Knotenpunkt mit vielen deaktivierten Kanälen sehe, ist das eine klare Botschaft: Er benutzt das verdammte Skript oder er ist mit vielen zPeers verbunden, die dieses Skript benutzen.
Die Liquidität fließt in beide Richtungen, ja ist langsam, aber hab Geduld. Lasse die node und den Organisum darum natürlich wachsen und fließen. Wenn du Barrieren in deb Weg setzt, wird der Traffic natürlich eine andere Route finden.
Ich habe versucht, vernünftig zu sprechen mit den Kollegen, die hierfür auch ansprechbar sind, die Situation verstehen und ihre Gebühren entsprechend anpassen. Langsam wird die Gier in die äußeren Ränder der LN-Galaxie isoliert werden.
Der Monat Februar sieht wie folgt aus, mit meinem bescheidenen Knoten, 70M Gesamtliquidität verteilt 50/50 und 40 Kanäle:
Insgesamt wurden 995 Zahlungen mit einer Gesamtmenge von 84 Mio. Sats weitergeleitet.
Der Spitzenwert lag bei 95 gerouteten Zahlungen und 9 Mio. Sats/Tag. Im Durchschnitt wurden im gesamten Februar etwa 20 txs/Tag mit insgesamt etwa 3 Mio. Sats/Tag geroutet. Nicht schlecht für einen so kleinen Knoten. Ich habe nicht allzu viele große Kanäle, nicht einmal einen Wumbo.
Mein Testknoten hatte: 5 Kanäle über 4M Sats, 14 Kanäle zwischen 4M und 1M Sats, 12 Kanäle bei 1M Sats und 9 Kanäle mit 500k Sats. Insgesamt 40 Kanäle (mehr oder weniger, einige schließen und öffnen sich).
Vergleichswerte des Monats Februar mit 6 vorhergehenden Monaten:
Zusätzliche Schritte, die ich unternommen habe
Ich habe die maximale HTLC-Menge auf 500k sats für alle Kanäle reduziert.
Ich habe meinen Knoten so konfiguriert, dass er im Hybridmodus läuft - Tor & clearnet. Dies hilft bei der Pfadfindung, wenn Tor „verstopft“ ist.
Ich aktiviere die Komprimierung meiner channel.db Datei, dies hilft der Reaktionsfähigkeit der Node und verringert die Anzahl der ausstehenden HTLCs
Ich habe die maximale Anzahl von HTLCs in der Datei lnd.conf auf 10 gesetzt.
Ich habe alle Peers so weit wie möglich offen gehalten. Manchmal ist Gossip über Tor wirklich unberechenbar und meldet Offline-Peers, auch wenn sie es nicht sind. Also habe ich den Peer, der offline zu sein scheint, aus der Peer-Liste entfernt und ihn wieder hinzugefügt, wenn möglich mit seiner clearnet URI. Nach ein paar Sekunden ist der Peer wieder online und der Kanal ist bereit. Sie können Thunderhub für alle diese Schritte verwenden.
Schlussfolgerungen
Im Allgemeinen war dieser Test für mich ein Erfolg. Mein Hauptziel war es, die Möglichkeiten und Kapazitäten dieses kleinen Knotens beim Routing zu sehen und daraus zu lernen, und zwar in Situationen mit hohem Verkehrsaufkommen. Ich möchte keinen meiner Mitstreiter entlarven, daher werde ich keine Screenshots mit Statistiken zu bestimmten Kanälen veröffentlichen. Aber ich kann sagen, dass viele von ihnen in diesem Monat in Bewegung geraten sind.
Einige wichtige Punkte, die ich beobachtet habe:
1 - Gebühren-Politik
0/0-Gebühren ziehen viel Verkehr an, aber es ist auch wichtig, Gleichgesinnte mit einer ähnlichen Politik bzw niedrigen Gebühren als Peer zu haben.
2 - Re-balancing
Die Peers mit hohen Gebühren kamen einfach zum Stillstand. Einige sagten, dass viele Knoten den Vorteil von 0/0 Gebühren ausnutzen um kostenlos zu rebalancen. Doch das stimmt nicht btw ich habe so etwas nicht bemerkt. Es gab nur wenige Bewegungen zu und von Peers mit hohen Gebühren, die meine Kanäle mit 0/0 Gebühren nutzten. Ich denke, dass der größte Teil der gerouteten Events einfach dem natürlichen Weg folgte: den billigsten und schnellsten Weg und die Knoten mit hohen Gebühren zu ignorieren.
Viele sagten, dass einseitig gefüllte Channels kein Routing sind und ausgeglichen oder geschlossen werden müssen. Das ist nicht wahr! Ich hatte viele „erschöpfte“ Kanäle - für einen Tag. Aber nach einer Weile fangen sie an, wieder Sats zu bewegen in die Gegenrichtung. Alles hängt davon ab, ob deine Node über ausreichend viele Kanäle und Liquidität verfügt bzw insgesamt ausgeglichen ist.
Wenn die gesamte ein- und ausgehende Liquidität ausgeglichen ist, du also mindestens 10-20-30 gute Kanäle hast (keine toten Verbindungen, nicht vom äußeren Rand der LN-Galaxie), dann wird Ihre Node natürlich auch in beide Richtungen routen. Wenn das Verhältnis von in/out mehr als 30% unausgeglichen ist, dann ja dann eginnen die Schwierigkeiten.
Während dieser ganzen Zeit habe ich NIEMALS in irgendeiner Weise einen Kanal ausbalanciert. Ich habe dafür kein automatisches Skript verwendet, nicht einmal manuell. Ich lehne mich einfach zurück und beobachte.
Ich wollte ja herausfinden, ob eine geringfügige Anpassung der HTLC beim automatischen Ausgleich des Kanals helfen kann, indem der Fluss dorthin umgeleitet wird, wo er benötigt wird und genügend Liquidität vorhanden ist.
3 - Ressourcen, Speicherauslastung
Ich habe festgestellt, dass mehr Speicher verbraucht wird, wenn mehr HTLCs in der Warteschleife hängen. Die Begrenzung der Gesamtzahl der ausstehenden HTLCs in der Datei lnd.conf hat also ein wenig geholfen. Ich bin mir nicht sicher, woran es lag, dass ständig mindestens 3-4 HTLCs für 5-10-15 Minuten im Warte-Modus waren. Lag es an meiner Node? Eine kaputte HDD? Meine Verbindung (ich war die ganze Zeit im Hybrid-Modus). Meine Peers? Allgemeine Tor-Probleme?
Ich verstehe die Bedeutung von ausstehenden HTLCs, aber nicht für so lange Zeit. Ich wünschte, ich könnte etwas dagegen tun, aber ich habe nicht genug Wissen oder die richtigen Informationen, wie man sie beheben kann. Vielleicht braucht LN auch einfach noch einige Verbesserungen in dieser Angelegenheit, die mit der Zeit kommen wird.
4 - Zentralisierung, Wachstum
Sehr wichtig ist die Position im Netzwerk, die Zentralität und die Verbindungen, die man hat. Ich habe eine Liste mit allen verfügbaren LN-Tools gepostet. Diese sind sehr gut in der Beobachtung deiner Peers, Routen usw. Diejenigen Peers, die weit am Rande des Netzwerks sind, werden nichts bewegen. Aber die Peers, die Verbindungen zwischen vielen der RoF und zentralen Knoten haben, werden deine Sats zum fließen bringen.
Wenn du also einen neuen Knoten oder sogar einen alten Knoten aber schlechte Verbindungen hast ändere dies umgehend. Versuchen, dich nicht mit Peers zu verbinden, die bereits dieselben Verbindungen haben wie du. RoF sind sehr gut, um zu expandieren, aber wenn du dich in vielen verschiedenen Ringen mit denselben Nodes verbindest, hilft das in keiner Weise, manchmal ist es sogar noch schlimmer, es entsteht eine Art Schleife, die nie wieder aufhört.
Expand your connections to nodes that are not in most of the RoF, be the bridge between them and RoF. Explore the LN peers every time you have time and take nodes, observe new nodes.
Connect with more nodes that are using at least 0 base fee and small ppm fee policy. Here is a huge list maintained by René Pickhardt with nodes “0 base fee” policy.
If you have a node with just 2-3 channels... and do not plan to grow more, you better just shut it down and use a simple LN moErweitere deine Verbindungen zu Knotenpunkten, die nicht in den gängigsten RoF sind, sei die Brücke für deine Peers zwischen ihnen und anderen RoF. Erkunde die LN-Peers jedes Mal, wenn du Zeit hast und nimm dir auch regelmässig Zeit, um nach Neuen Partnern zu suchen.
Suche nach solchen, die 0 Grundgebühr und eine geringe ppm-Gebühr Politik verwenden. Hier ist eine lange Liste, die René Pickhardt für die "0 base fee" Politik pflegt.
Wenn du einen Knoten mit nur 2-3 Kanälen hast und nicht planst, mehr zu wachsen, solltest du deine Node besser abschalten und eine einfache LN Mobile Wallet verwenden. Damit hilfst du weder dem Netzwerk noch dir selbst. Wir alle wissen, dass es schwer ist, Sats zu stapeln, aber niemand zwingt uns, einen guten Knoten mit guter Liquidität zu betreiben. Wenn du dir das nicht leisten kannst oder nicht zutraust ist es keine Schande, sich dies einzugestehen und darauf zurückzukommen, wenn deine Lernkurve und Finanzen es erlauben.
Mein Experiment war es hiernach, zu sehen, ob mit relativ kleinen Kanälen (1-5M sats) ein gutes Routing für alle ermöglicht werden kann. Ja, man könnte 2-3 große Kanäle mit 10-20 Mio. Sats haben, aber das halte ich für zentraler, da es mehr TXs auf einen einzigen Punkt konzentriert. Anstelle von nur 1 x 20M könnte ich 4 Kanäle mit je 5M-Satelliten und mehr Verbindungen haben, die mehr Konnektivität bieten. Ja, es ist besser, Kanäle mit mehr als 3M Sats zu haben, aus vielen Gründen.bile wallet. You are not helping at all the network, neither yourself. We all know that is hard to stack sats, but nobody is forcing you to run a good node with good liquidity.
My experiment is to see that if with relatively small channels (1-5M sats) can obtain good routing for all. Yes you could have 2-3 big channels of 10-20M sats but that I consider more centrality, concentrating more txs into only one spot. Instead of just 1 x 20M I could have 4 ch x 5M sats each and more connections, providing more connectivity. Yes is preferably to have channels bigger than 3M sats, for many reasons.
5 - Nutze deine Liquidität!
Wenn du bereits einen LN-Knoten hast, nutze ihn, verdammt noch mal! Für Zahlungen. Wo immer sich einen Händler findet, der LN akzeptiert, bezahle ihn mit Sats und am besten über die eigene Node. Nicht, dass dies dem Netzwerk helfen würde, aber man macht seine Node im Netzwerk sichtbarer. Dies treibt die Liquidität voran. Deshalb heißt sie "Liquidität", weil sie FLIEßEN und sich bewegen muss, um etwas Großes und Wunderbares zu schaffen.
Wenn du nur auf deinem LN-Knoten sitzt und darauf wartest, dass andere darüber routen und du ihnen Gebühren berechnest... IST DAS EINFACH NUR DUMM.
Hier findest du eine Liste mit tollen Orten, an denen man seinen LN-Knoten zur Bezahlung nutzen kann.
Next step: #March1ppm
For March I would test the same scenario but moving to 0/1 (0 base fee/1 ppm) only.
Also will set max HTLC to 500k sats to all channels bigger than 1M and 150k to all smaller than 1M sats.
UPDATE 1
Im März wollte ich das gleiche Szenario testen, aber auf 0/1 (0 Grundgebühr/1 ppm) umstellen.
Außerdem habe ich die maximale HTLC auf 500k sats für alle Kanäle > als 1M und 150k für alle Kanäle < als 1M sats gesetzt.
UPDATE 1
Nach 1 Woche mit max HTLC auf 500k sats, sah ich zu viele fehlgeschlagene txs. Also habe ich angefangen, die Richtlinien ein wenig zu ändern. Jeden Morgen während meines Kaffees schaute ich mir alle bisher gerouteten TXs und Kanäle an und passte die maximalen HTLC so an, wie ich sie auf meiner Seite habe. Das heißt, wenn ein TX an meinem Knoten ankommt, wird automatisch geprüft, ob der Kanal groß genug hierfür ist. Wenn das Gleichgewicht auf meiner Seite größer als 1M sats ist, stelle ich einfach 800-900k sats max HTLC ein oder noch höher - wenn notwendig.
Zum Beispiel habe ich in diesem Kanal von insgesamt 1 Mio. Sats nur 112 765 Sats zur Verfügung. Ich werde also eine maximale HTLC von 110 000 Sats festlegen (gerundet, muss nicht genau sein), weil ich nicht mehr als das weiterleiten kann. Wenn ich also eine neue Zahlung weiterleite, die größer ist als diese, wird diese Route automatisch nicht geprüft.
Aber ich sehe regelmässig, dass die Benutzer mehr und mehr MPP betreiben, so dass ich nicht davon ausgehe, dass jemals eine tx größer als 1Msats geroutet wird sondern diese immer in kleinere Teile aufgeteilt werden wird.
Dieser Prozess hat mich jeden Morgen 5-10 Minuten gekostet, keine große Sache, ich habe nur wenige Kanäle, nicht hunderte, also kein Bedarf für ein automatisiertes Skript, um die maximale HTLC einzustellen.
Nach einer Woche, in der ich dies tat, bemerkte ich ein natürlicheres Routing mit weniger fehlgeschlagenen HTLCs.
Eine weitere Aufgabe, die ich alle 4-5 Stunden/Tag erledige, ist zu prüfen, ob es "Offline"-Kanäle gibt, insbesondere solche, die normalerweise viel routen. Manchmal schlägt die Gossip-Meldung fehl und zeigt Kanäle im "Offline-Modus" an, die aber in Wirklichkeit nicht offline sind.
Also gehe ich zu Thunderhub - Peers, entferne den "toten" Peer und füge ihn wieder hinzu. Nach ein paar Sekunden ist der Kanal wieder "online". Wenn der Peer wirklich nicht online ist, schlägt der Prozess fehl, so dass man nichts tun muss, sondern es einfach später erneut versuchen kann.
Diese Aufgabe kann mit einem BoS-Skript erledigt werden, den man so programmieren kann, dass er alle 5h ausgeführt wird. Für das Experiment habe ich mich jedoch entschlossen, dies manuell zu machen (ich bevorzuge das aber auch generell). Ich habe nicht viele Verbindungsabbrüche, da ich im Vorfeld Wert auch gute Peers lege.
Ich habe den März mit einer channel.db-Datei von 1,3 GB begonnen.
UPDATE 2
Am 15. März habe ich eine Datenbank-Komprimierung durchgeführt. Sie war bereits 2,2 GB groß und brauchte 5 Stunden, um dies auf 1,2 GB zu reduzieren. Ich weiß nicht, wie sich das genau auswirkt, aber nach ein paar Stunden begann der Knoten wie verrückt zu routen und erreichte mehr als 100 geroutete Txs. Anm.: Diese Komprimierung erfolgt heutzutage automatisch bei Neustart von LND.
Es wurde keine große Menge an Sats, nur ca 7M Sats geroutet in 100+ txs. Ich denke, dass die Strategie, die maximale HTLC für die Kanäle mit weniger Liquidität auf meiner Seite anzupassen, sehr viel mehr geholfen hat.
Seit dem 15. März habe ich auch eine weitere Strategie eingeführt: Für alle Kanäle mit mehr als 1 Mio. Sats habe ich die Mindest-HTLC auf 99 Sats eingestellt. Nur für einige wenige Kanäle, bei denen ich noch die 0/0-Gebühren-Politik anwende und kleine Zahlungen weiterleiten möchte, habe ich es bei 1 Sat Minimum belassen. Es lief hiernach wirklich sehr viel besser... !
Schau dir die Anzahl der Kanäle an. Ich habe sie nie ausgeglichen. Ich begann mit 2en mit Gleichgewicht auf meiner Seite und 3en mit Gleichgewicht auf ihrer Seite. Nach einer Woche waren sie perfekt ausgeglichen.
Ich habe ABSOLUT NICHTS getan! Keine Skripte, kein automatischer Ausgleich, keine Gebühren ausgegeben, nur die Anpassung max HTLC und 0 Grundgebühr und 1 ppm.
Einige andere Nodes begannen, Kanäle mit meinem Knoten zu öffnen, ich weiß noch immer nicht, warum. Vielleicht weil einige Auto-Pilot-Skripte meinen Knoten als "geeignet" empfohlen haben. Aber die Sache ist, dass sie hohe Gebühren verwendeten... also schloss ich sie einfach. Ich möchte keine gierigen Peers. Das wirkt sich auch auf mein Routing aus. Wenn ich Peers mit hohen Gebühren habe, passiert folgendes... die Gesamtzahl der gerouteten Txs sinkt. Wenn ich diese Kanäle schließe, was passiert dann am nächsten Tag? Doppelte Anzahl von gerouteten Txs.
Fazit für März:
Es war ein ziemlich guter Monat, mit einer 0/1-Gebührenpolitik. Außerdem sollte ich erwähnen, dass ich für alle Kanäle mit > 1 Mio. Sats die Mindest-HTLC auf 9 Sats eingestellt habe. Alle anderen kleinen Kanäle bleiben bei mindestens 1 Sat.
Insgesamt habe ich 1779 txs geroutet und 113 sats an Gebühren erhalten, mit einer Gesamtzahl von 123.218.850 Sats, die in beide Richtungen bewegt wurden, wobei 43 Kanäle immer online waren. Ich hatte 2-3 Kanäle, die tot waren (die Betreiber haben mich über ihre Probleme informiert und ich habe sie nicht geschlossen).
Die Methode, die maximale HTLC für jeden Kanal entsprechend meiner seitlichen Liquidität einzustellen, scheint recht gut zu funktionieren. Ich stelle fest, dass einige "schlafende" Kanäle wieder aufwachen und einige Sats bewegen. Einige aktivere Channels liefen besser und bewegten eine ziemlich große Menge an Sats.
Alles hängt auch von den Peers und den Peers der Peers ab. Wenn du nur ruhende Peers hast, die nur darauf warten, dass andere Sats verschieben und die selbst keine LN-Zahlungen tätigen, dann sind diese Peers eine Sackgasse und sollten besser ersetzt werden. LN Sats müssen fließen, danit das Netzwerk wachsen kann.
10.April
Für April habe ich die ppm-Gebühr auf 10 erhöht. Lass uns einmal ansehen, wie das lief.
UPDATE 15. April
Es war ein konstanter Durchschnitt von 50 txs pro Tag. Aber ich muss erwähnen, dass ich viele Neustarts meines Knotens machen musste, wegen einiger anderer Experimente mit LNbits.
Außerdem habe ich einige Änderungen an meiner lnd.conf Datei vorgenommen und beobachtet, wie es mit der Plage der force-closed Kanälen läuft.
Hier ist meine lnd.conf-Anpassung bis zu diesem Zeitpunkt.
UPDATE 19 April
Man kann seine mx HTLC wie gesagt pro Kanal manuell einstellen oder automatisieren. Ich ziehe es nach wie vor vor, dies jeden Morgen manuell zu tun, einen Kaffee zu trinken und meinen Knoten nach einer arbeitsreichen Nacht zu überprüfen und passe nur die Kanäle an, die es meiner Meinung nach benötigen.
Ich sehe wirklich nicht die Notwendigkeit, ständig unnötige, obsessive Anpassungen vorzunehmen. Das ist "verfälschter" Traffic über LN - und man zahlt Gebühren für nichts.
Pfadfindung und Routing können gesteigert und effizienter gestaltet werden, wenn die gerouteten Zahlungen den richtigen Weg finden, dorthin, wo die Kanäle mehr Liquidität vorfinden und sich entsprechend ausbreiten können. Wenn ich diese Liquidität "verstecke", wird das Wasser nicht mehr durch dieses Rohr fließen, sondern andere Wege nehmen.
Wenn du niedrige Gebühren verwendest, aber die Liquidität zurückhälst, kommt die Nachricht zwar immer noch an, wird aber zurückgeschickt und man hat noch mehr Fehlleitungen, d. h. Ihr Knotenpunkt wird nicht mehr als gute Route angesehen.
Ja, einige "Befürworter des Datenschutzes" werden sagen, dass die Offenlegung des Kontostandes eines Kanals mit mac HTLC die Offenlegung des Kontostandes der Node bedeutet. Das ist so, als würde man sich hinter einem Baum verstecken und Kugeln ausweichen. Nutzlos. Die Balance der Node Channel kann sehr leicht mit vielen anderen Methoden und sogar auf öffentlichen Explorern ermittelt werden.
Sorge dafür, dass das Wasser gut fließt und mit der Zeit kannst du die Gebühren nach Belieben anpassen. Wichtig ist, dass das Wasser kontinuierlich fließen kann..
UPDATE 22. April
Ich habe einige kleine alte Kanäle auf mehr als 2.5M sats erhöht. Das Ergebnis nach einigen Tagen ist, dass die Anzahl der gerouteten Txs pro Tag hier bereits die 200 überschritten hatte. Wir werden im Verlauf sehen, ob das nur vorübergehend war oder ein neuer Trend. Mir war jedoch aufgefallen, dass immer mehr Leute LN für regelmäßige Zahlungen nutzten (nicht nur für nutzloses Rebalancing).
In der letzten Aprilwoche hatte ich einen großen Anstieg der Zahl der weitergeleiteten Zahlungen mit einem Maximum von 227 txs. Danach ging die Zahl auf 50-60/Tag zurück.
Im April hatte ich viele Neustarts und Änderungen, was sich erheblich auf die Anzahl der weitergeleiteten TXs auswirkte. Außerdem habe ich viele Kanäle gewechselt (Geschlossene und Neue), und es dauerte seine Zeit, bis ich wieder einen guten Fluss an Txs erreicht hatte.
Die Tatsache, dass ich die Gebühr auf 10 ppm erhöht habe, hat sich nicht unbedingt auf die Weiterleitung ausgewirkt.
Geduld ist der Schlüssel.
Ich hatte gerade diesen Tweet von Alex Bossworth gesehen und beschlossen, die Gebühren für den nächsten Monat Mai auf 1ppm zu senken (Zero Base Fee Forever). Hier habe ich eine Antwort für Alex gepostet.
Ich war ab hier überzeugt, dass es wichtiger ist, ein stabiles und günstiges Zahlungsnetzwerk aufzubauen, als ein "Gebührenrennen" zu starten und sich gegenseitig zu bescheißen. Ich glaube nicht, dass Alex von seinen Knotengebühren leben kann...
UPDATE 5. Mai
Diesen Monat werde ich ein weiteres "Experiment" starten. Abgesehen von einer selektiven ppm-Gebühr, zwischen 0 und 10ppm, werde ich weiterhin mit den max HTLC spielen.
Mein Plan ging so:
max HTLC auf 299k sats setzen, wenn der größte Teil der Liquidität auf meiner Seite liegt und der Kanal größer als 2M sats ist.
max HTLC auf 199k sats, wenn der größte Teil der Balance auf meiner Seite ist und der Kanal kleiner als 2M sats ist.
Passe die maximale HTLC an, wenn sich das Gleichgewicht dem eingestellten Höchstwert nähert, und gehe auf 199k und dann auf 19k, wenn es weniger wird.
Passe die maximale HTLC in 3 Schritten an, wenn sich das Gleichgewicht wieder auf meiner Seite einpendelt.
In der Folge war es nicht notwendig, die Kanäle ständig zu aktualisieren (was nicht empfohlen wird) und eine bestimmte Anzahl von Txs durch bestimmte Kanäle zu tunneln.
Ich hoffe, dass die Benutzer mehr und mehr MPP (Multi-Part-Payments) verwenden werden und eine bessere Pfadfindung und schnellere Routen haben w erden durch Experimentieren und Beobachten Ihres Knotens.
UPDATE 22 Sept 2022: René Pickhardt just dropped this amazing article, that more or less have the same conclusion like my experiment:
The power of valves for bUPDATE 22 Sept 2022: René Pickhardt hat gerade diesen erstaunlichen Artikel veröffentlicht, der mehr oder weniger die gleiche Schlussfolgerung wie mein Experiment hat:
MAY DER ₿ITCOIN MIT DIR SEIN !
Wenn du diesen Artikel zu schätzen weisst, können du einige Satoshis an
abracadabra senden, für die Übersetzung auf Deutsch:
an @LNtxBot Telegram abracadabra
oder an diese Lightning Adresse: arbadacarba@ln.tips
Für alle, die sich nicht auf Substack anmelden wollen, werden alle DarthCoin Bitcoin Guides auch auf diesem Telegram Channel veröffentlicht, um die Suche zu erleichtern und um den Überblick zu behalten.
Um
auf Substack zu abonnieren, klicke hier:be on substack, click here:
Sehr guter Überblick für etwas fortgeschrittene LN Node Betreiber.