Lightning - Erfahrungen [Liquidität, Gebühren]

Ein herzliches Hallo in die Runde!

Ich hab mir erlaubt mal eine Experimente, Erfahrungen, Recherchen und Überlegungen zu teilen. Vorab gleich mal ein „Sorry“ für den englisch/deutsch Mix im Text, aber irgendwie sind englische Begriffe in einigend Fällen einfach griffiger und dann ist es auch einfach Gewohnheit. Des weiteren ist folgendes nicht als Weisheit letzter Schluss zu betrachten, sondern ein versuch wie ich die Dinge verstanden habe, strukturieren wider zugeben. Das ganze wurde etwas länger als anfangs Gedacht.

Viel Spaß beim Lesen, Kritik, Anregungen, Richtigstellungen erwünscht!

Allgemein:

Eine Node ist eine Hotwallet somit immer am Netz und online, der Privatkey liegt auf der Node. Das soll keine Panik verbreiten nur es ins Bewusstsein holen. Im Normalfall und im Gegensatz zu einer Bitcoin Onchain Transaktion wird nicht an eine Lightning Wallet Adresse gesendet. Sondern von der Empfangende Seite eine Rechnung (Invoice) gestellt. Das heißt das die satoshis werden „gezogen“. Es gibt so etwas wie ein Lightningwallet Adresse nicht im klassischen Sinne nur die Public-Adresse der Node. An die auch unter gewissen Umstände „gesendet“ wird (KeySend) hier werden satoshis von der lokalen Seite eines Kanals in auf Gegenseite geschoben. Oder LNUrlPay wo der Node aufgefordert wird eine Rechnung zu stellen.

Channel:

Eine P2P Verbindung zwischen 2 Nodes. Wie eine Rohrleitung die mit einer bestimmten Menge an satoshi gefüllt wird und diese Volumen kann hin und her fließen.

Limits:
• minimum 20000 satoshi
• maximum 2^24 - 1 satoshi (0.16777215 BTC)
• Single Transaktionslimit 2^32 millisatoshis (0.042949672

Wumbo-Protokol
Muss eigens aktiviert werden und ist alles größer als 0.16 BTC
soweit keine Limits mehr. Soft Limits default 10 BTC Größe und 0,5 BTC Payment.

Beim öffnen eines Kanals (Funding) wird Guthaben auf eine Multisig-Adresse eingezahlt die von beiden Teilnehmern kontrolliert wird. Es werden 3 Transaktionen erstellt und signiert aber nur eine dem Netzwerk bekannt gegeben. Die eine Transaktion, die gesendet wird, finanziert den Kanal und gibt eine Multisig-Output aus. Es wird von jedem unterschrieben, der den Kanal finanziert. Wenn diese Finanzierungstransaktion eine ausreichende Bestätigung erhält, gilt der Kanal als offen.

Die verbleibenden zwei Transaktionen, die erstellt, aber nicht veröffentlicht werden, sind Commitment-Transaktionen. Diese werden von beiden Zahlungskanal-Partner signiert, und jeder Peer speichert seine eigenen Commitment-Transaktionen zur späteren Verwendung in einer möglichen zukünftigen Closing-Transaktion. Die Commitment Transkation wir von beiden Seiten benutzt um quasi den Kontostand zu führen da jeder die Signatur des anderen hat. Wird der Kanal geschlossen und die Multisig-Adresse an das Netz bekannt begeben bekommt jeder seinen letzten vereinbarten Kontostand.

Normal wird kooperativ geschlossen. Wird ein schließen erzwungen weil z.B. der andere Node ewig offline ist und die Liquidität blockiert wird die freigab auf die Onchain verzögert. Sobald das Schließen eingeleitet wird kann der Kanal nicht mehr verwendet werden. Die schließende Seite trägt die OnChain Gebühren in beiden fällen. Edit 24.08.21 Falsch: Die Schließungskosten bezahlt IMMER derjenige der den Kanal eröffnet hat.

Inbound:

Liquidität auf der Remote Seite des Kanals ergo eingehende Liquidität/Zahlungen erhalten

Outbound:

Liquidität auf der lokalen Seite des Kanals ergo ausgehende Liquidität /Zahlungen versenden

Die Überlegung welchen Zweck der Node erfüllen soll, legt dann fest was einem wichtiger ist. Bin Ich Händler und verwende eine Node um Zahlung meines Webshops anzunehmen bin ich eher bestrebt mehr Inbound zu haben. Bin ich Einkäufer dann natürlich eher Outbound.
Soll der Node hauptsächlich Zahlungen weiterleiten ist man versucht die Balance des Kanals auf 50% (Optimal) zu haben (Balancing von 1). Damit der Kanal am effizientesten genutzt werden kann.

Die maximale Menge die Versenden oder Empfange werden kann, ist auf die Größe des Größten Kanals begrenzt nicht die Summe. ( Ausnahme Multipath-Payments).

Wenn man das Beispiel vom Bild nimmt heißt das es können maximal 3M versendet aber 9.8 M empfangen bzw. erhalten werden. Dies ändert sich dann natürlich wie die Balance steht.

Routing:

Hier muss man wissen das die Gesamtsumme links und rechts abzüglich Routing-gebühren gleicht bleibt, das heißt es ist trotz der hohen Inbound-Menge nicht möglich mehr als 3M weiterzuleiten. Sprich das was rein kommt muss auch wieder raus gehen. Ich kann also nur die Menge weiterleiten die ich in einen anderen Kanal als Outbound habe.

Überarbeitung 06.05.2021: (Muss diesen Abschnitt korrigieren da nicht ganz klar)
##Begin
Routing-Gebühren bekommt man nur für das weiterleiten von Liquidität. (PushOut) Zur verrechung werden die werte am outbound channel genommen. Es ändert aber an der ganzen vorgehensweise nicht viel. Speziell wenn man zu beginn überall die gleichen gebühren setzt. Man weis auch am anfang gar nicht welche richtungen und routen gut gehen. Dh man wird im nach hinnein dort wo viel volumen raus geht langsam die Gebühren anziehen.
##END

Das Bringt mich zu den Gebühren im allgemeinen, es ist scheinbar so das sehr viele die Standard Einstellungen belassen. Hat aber so scheine Schattenseiten. Es folgen ein paar Überlegungen.

Base Fee:

Grund Betrag unabhängig von der weiter geleitet Menge an Satoshis, Standard Wert 1000mSat = 1Sat das scheint es nicht viel zu rütteln zu geben hab aber auch schon krumme werte wie 300mSat oder 3624mSat oder auch 0 gesehen.

Fee Rate:

In ppm (parts per million) der Standardwert ist hier 1 ppm was unter normalen Umständen viel zu wenig ist. (meine Ansicht)

Wie berechnen sich nun die Gebühren. {satoshi* FeeRate+BaseFee] mit dem Werten von oben nun ein Beispiel:

Gesendet werden 1M Sat: 0,000199sat1 000 000sat+1sat=200Sat→ 200 000mSat*
image

Also pro Million Satoshi die der Kanal weiterleitet bekommt man 200 Sat. Für den der die Zahlung macht ist das aber nicht alles sonder die gebühren pro Node (HOP) werden addiert. Läuft so eine Zahlung von 1MSat über 3 Nodes, die der Einfachheit halber jetzt die selben Gebühren verlangen sind die Gebühren 600Sat von dem man 200Sat abbekommt.

Der Sender kann allerdings die Gebühren bestimmen die er bereit ist zu zahlen und so wird die Günstigste Route gesucht. Möchte hier hinzufügen das aber ein Stabiler Node mit großen Kanälen ein bessere Reputation hat als günstige Routing gebühren. Zugverlässlichkeit und Alter wiegt also stärker. (Reputation – BOS Score – von Lightning Labs)

Jetzt kommt man zu der Überlegung welche Gebühren sind Sinnvoll und vielleicht auch wirtschaftlich. 1ppm als Standard ist es definitiv nicht. In eine Speziellen Verbund von Nodes natürlich schon zweit Geschäftspartner z.B. in einem Privaten Kanal die sich Gegenseitige keine Gebühren verrechnen oder nur sehr wenig. Und man merkt sofort das Ganze ist stark abhängig von der Größe des Kanals und der Dauer diesen offen zu halten.

Ein Betrachtung wäre:

(Eröffnungskosten + zu erwartende Schließkosten) / Kapazität x1 000 000 =ppm

Nehmen wir hier nun auch ein Beispiel was das konkret an Gebühren bedeuten würde.
Der Einfachheit wieder, gerade Zahlen und die optimistischen annahmen die Schließkosten sind gleich wie die Eröffnungskosten

(1500sat + 1500sat) / 10 000 000 Sat x1 000 000 = 300ppm

Das heißt man bekommt seine OnChain kosten gedeckt, wenn einmal der Kanal komplett gefüllt wird. Bei einem Kanal mit 10M scheint das auch noch schön zu passen und durchaus realistische Betriebsparameter. Ist der Kanal jedoch nur mehr 1M groß (bei gleichen kosten) wären die nötigen Gebühren dafür schon 3000ppm was definitiv zu hoch ist weil es genug andere Routen geben wird die weit günstiger sind. Lässt man die Gebühr bei 300ppm muss ich zehn mal die 1M empfangen.

Hier sieht man schon das das ganze eine gesunde Balance benötigt zwischen Kanal Größe und Dauer. Auf alle fälle läuft man mit zu niedrigen Gebühren Gefahr das einem ständig der Kanal leer gezogen wird weil die billige Liquidität abgezogen wird. Ja, sie kommt auf einem anderen Kanal wieder rein aber zerstört evtl. den Balance werte. Die Gebühr von 199ppm hab ich gewählt weil das nach diesen Überlegung bei diesem spezifischen Kanal 3 mal das Volumen weitergeleitet werden muss bis zum break even, der bei vielen kleine Bewegung durch die base fee früher eintritt.

Eine Weitere Möglichkeit: Dynamische Gebühren

Die Idee hierbei ist die Gebühren gering zu halten solang der Kanal gefüllt ist um Liquidität aus den Kanal zu bekommen und zu erhöhen wenn die Liquidität fällt um den Abfluss zu „bremsen“ Angebot nach frage. Um So eine Balance im Kanal zu „steuern“. Oder man staffelt andersrum. Also um den Zufluss zu bremsen wenn der Kanal zu voll wird.

Als Beispiel ein Kanal mit 10M Größe bremst das leeren (deplete)

  • Local Balance 10-7M – 50ppm
  • Local Balance 7M-3M – 100ppm
  • Local Balance 3M-0M – 200ppm

Als Beispiel ein Kanal mit 10M Größe bremst das füllen (supply)

  • Local Balance 10-7M – 200ppm
  • Local Balance 7M-3M – 100ppm
  • Local Balance 3M-0M – 50ppm

Das kann natürlich über Skripte automatisiert werden, hier wäre zu erwähnen das ein zu häufiges ändern der Gebühren beim routing „abgestraft“ wird also eigentlich ein zu häufiges erhöhen weil beim es beim routing zu Fehlschlägen kommen kann. Das kann dann zu ähnlich Fehlern führen das nicht geroutet werden kann wegen zu wenig Kapazität. Routen schlägt fehl weil ständig die Gebühren erhöht werden.

Hier noch als Beispiel einer Preisliste:

Es gibt noch zwei weitere Werte in den Einstellung zum Kanal die ich auch beleuchten möchte.

Die Passagen sind von mir aus dem Englischen übersetzt.

CLTV Delta

TimeLockDelta (oder cltv_expiry_delta) ist die Mindestanzahl von Blöcken, die ein Node zum Ablauf von HTLCs hinzufügen muss. Mit anderen Worten, dieser Wert repräsentiert die erforderliche Lücke zwischen den Zeitsperren der eingehenden und ausgehenden HTLC zu diesem Knoten . Sobald eine HTLC-Zeitüberschreitung vorliegt, kann sie entweder erfüllt oder abgelaufen sein. Dies bedeutet, dass der Node darauf achten muss, diesen Zeitpunkt zu umgehen und sowohl die angebotenen als auch die empfangenen HTLCs zu erfüllen. Wenn der Knoten dies nicht rechtzeitig erfüllt, kann der Peer sein Geld zurückerhalten, indem er die Timeout-Transaktion ausgibt.

Die Zeitsperre kann bis zu 14 * 144 = 2016 betragen oder die erwartete Anzahl von Blöcken, die innerhalb von 14 Tagen abgebaut werden sollen. Im Allgemeinen ist das CLTV-Delta ein abwegen von:

Je höher Sie diesen Wert wählen, desto länger kann Ihr Knoten offline sein, ohne dass Sie aufsteigen, um Geld zu verlieren. Andere Nodes entscheiden sich jedoch möglicherweise dafür, Zahlungen nicht als Routing-Prozess über Sie weiterzuleiten, wenn die Einstellung der Kette technisch so lange dauern kann wie das CLTV-Delta.

Der Grund, warum im (Gossip Protocol update_channel (die 1 ml darstellt) verschiedene Werte angezeigt werden, liegt wahrscheinlich darin, dass Implementierungen unterschiedliche Standardwerte verwenden und die Standardeinstellungen mit verschiedenen Versionen geändert haben. Ich denke, es war 144 für eine der Implementierungen und es kam auf 6 oder 9. Eclair Mobile Wallet, das hauptsächlich private Kanäle erstellt, die Sie bei 1-ml-Benutzern nicht sehen 2016 da Mobiltelefone möglicherweise längere Ausfallzeiten haben

Ich hab allerdings auch die Information das der kleinste Wert 18 sein soll und nicht wie oben 6.
Momentan scheint ein gängiger Standard Wert 40 zu sein ich habe 144 gewählt weil das ca. 24h in Blockzeit bedeutet. Bei all den technischen Details von oben ist aber mein Hauptanliegen hier zu verstehen das die Uhr bzw. der Taktgeber für das Lightning Protokoll wieder die Blockzeit der Mainchain ist und hier noch mal auf Bitcoin ist Zeit verweisen. Für mich eine sehr erhellender Artikel.

Der MAX/MIN HTLC Size wert dient angeblich nur zur Unterstützung der Pfadfindung Hilfreich beim Mobiltelefonen. Es gibt auch noch einen unterschied zwischen Pfad finden und dem Routing selbst. Also wenn ein Pfad zwischen mehren Nodes gefunden wird heißt es noch nicht das auch eine Zahlung geroutet werden kann. Beim Rebalacing starte ich einen Versuch darauf näher einzugehen.

Rebalance:

Damit das überhaupt klappen kann braucht man mindestens 2 Kanäle einen mit genug Outbound und eine mit Genug Inbound. Bei einem Rebalance ist das ein Versuch eine Zahlung an sich selbst zu stellen. Und dadurch Lokales Gut haben aus einem Kanal zu schieben und auf einem anderen Lokalen Kanal zu empfangen. Optimal wäre natürlich ein Dreieck und ein Gebühr von 0 für diesen Vorgang. (Es gibt koordinierte Rebalacing Vorgänge in Gruppen die die Gebühren für eine weile senken alle beteiligen ihre Zahlungen durch führen und danach wieder heben) Aber meist fallen einfach gebühren dafür an ist eben auch ein Geschäft.

Hier habe ich versucht 10k Sat zu senden. Man wählt den Kanal der viel lokales Guthaben hat und den Kanal der Empfangen soll. Bei Schritt zwei wird eine Gebühr geschätzt und die Anzahl der Nodes. Das heißt es gibt mal einen Pfad das ist ein gutes Zeichen. Ich hab hier allerdings die Erfahrung gemacht das man mit der Schätzung nie hin kommt. Bei CLI Tools wie BOS bekommt man zumindest eine Fehlermeldung meist ist es zu wenig Gebühr oder die Route ist einfach nicht möglich weil auf den Nodes dazwischen nicht genügen Kapazität auf der richten Seite des Kanals liegt.

Die Schätzung mal 10 hilft schon mal das ein Versuch zum Routen überhaupt unternommen wird sonst bricht der Vorgang gleich ab. Hier wurden 1,5 Sat für den Vorgang vorgeschlagen was für 7 Hops ohne hin unrealistisch ist. Ich hab gleich 20 Sat als Maximum Gesetz. Das hört sich jetzt extrem an aber am Ende gelingt das Routing dann mit 3 Hops und 5,2Sat Gebühr ist doch voll Ok oder nicht ?

Warum die Schätzung und die echte Durchführung so stark von einander abweichen ist mir noch ein Rätsel. Ach ja und um so höher der Betrag desto schwieriger wird es mit mehr als 100K gelingt mir das sehr selten.

Liquidität ,Pool und Marktplätze:

Nun jetzt da ich euch schon Lange auf die Folter gespannt habe, die große Frage: Wie kommt man selbst oder jemand anders zu Liquidität. Meist ist man ja auf der suche nach Inbound also Teilnehmern die bereit sind einen Kanal zu öffnen. Hier lohnt es sich zu sagen das vom Autopilot abgeraten wird.

Lösung 1: Ausgeben

Du hast einen Kanal geöffnet und kannst eigentlich sofort beginnen sie auszugeben, d.h. So bekommt man automatisch inbound Liquidität. Hier kann man auch den „Trick“ verwenden eine Kanal zu einer Node einer Custodial Wallte zu öffnen wie „Wallet of Satoshi“ oder LNTXBOT. Eine Rechnung stellen und sich selbst auf der andere Seite zu bezahlen.

Lösung 2: Nach Kanälen fragen

Passiert ja auch hier im Forum. Hier kann es so weit gehen das man sich Gegenseite soweit Vertraut, das die eine Partei per KeySend 50% des Kanales pusht und die andere eine BTC TX sendet und somit die Rechnung begleicht. Ist die Schnellste Möglichkeit 50/50 herzustellen.

Lösung 3: Exchanges

Ja klingt verrückt mit LN Bitcoins Onchain Bitcoins kaufen. z.B. zigzag.io, fixedfloat.com

Lösung 4:LOOP and POOL

Loop ein Services von Lightning Labs, inverse submarine swaps um Satoshis off oder On-Chain zum nehmen. Der Vorteil, der Vorgang ist non-custodial, der Nachteil, teuer, es fallen Onchain, Service und Routing Gebühren an, da ist man schnell bei 50-60kSat.

Loop In – On chain BTC ins LN senden Outbound Liquidität.

Loop Out – In Remote Kanäle LN Liquidität schieben und On-Chain BTC erhalten. Damit mit kann man auch BTC abschöpfen ohne den Kanal zu schließen.

Pool auch ein Service von Lightning Labs ein non-custodial Markplatz.
Hier kann man entweder auf Eingehende Liquidität bieten [BID], Ausgehende Liquidität verkaufen [ASK].

Das besondere an den Marktplatz ist das es sich um sealed-bids handelt das heißt es gibt kein Oderbruch. Das einzige das man sieht ist die Vergangenheit ob Orders durch geführt wurden oder nicht. Wie ein Ebay Auktion nur sieht man eben nicht wie die anderen Gebote stehen auch die Gegenseite sieht nicht wie hoch geboten wird.

Es gibt jetzt zumindest auch schone eine GUI, über die CLI hat man noch mehr Einfluss auf gewisse Einstellungen. Weil das auf den ersten blick alles sehr verlockend klingt Beschreibe ich den Ablauf etwas genauer. Wie läuft das ganze nun ab, zu erst muss man eine Account eröffnen um die PoolWallet zu befüllen. Das ist hier wieder eine Multisig Adresse Zwischen dem Pool Service und der LND Wallet. Hier fallen schon mal On-Chain gebühren an.

Der Account hat ein Ablaufdatum Standard 2016 Blöcke. Nach Ablauf der Zeit muss man die Lebensdauer entweder verlängern oder ihn schließen. Hier fallen auch OnChain gebühren an.

Will man Liquidität Verkaufen muss man natürlich die Menge der geplante Kanalgrößen + OnChain Gebühren auf die Wallet senden. Um Einzukaufen zumindest die Prämie die man gewillt ist zu bezahlen + OnChain Gebühren.

Alle 10 Minuten gibt es eine Batch/Stapel der versucht Nachfrage und Angebot zu bedienen. Alle erfüllten Orders werden dann in einer einzigen Transaktion durch geführt sprich es können mit einer TX tausende Kanäle Gleichzeitig geöffnet werden. (Die TX muss allerdings in einem Block sein) Wer es genauer wissen will. Batch Execution

DESIRED INBOUND

Höhe der gewünschten Liquidität Es wird in Units gehandelt 1 Unit = 100.000 sat oder ein mehrfaches davon. (Info das GUI hat einen Bug wenn der Browser nicht auf Englisch ist beim parsen des Eingabefeldes und den Umgang mit . und , bug fix ist im master branch schon gemacht, am besten mit copy paste arbeiten oder CLI)

DESIRED OUTBOUND

Höhe der Liquidität die man Anbieten möchte es gilt analog obiges.

BID PREMIUM

Höher der sat die man bereits ist als Prämie zu zahlen

ASK PREMIUM

Höhe der sat die man als Prämie erhalten möchte

MINIMUM CHANNEL SIZE

Die Minimum Kapazität pro Kanal in den die Units zusammen gefasst werden.
So steurt man ob man eher mehr Kanäle haben möchte oder größeres Volumens

MAX BATCH FEE

Die maximal OnChain Kosten die der Batch Block haben soll

MIN NODE TIER

T1 ist jeder node der schon mal ein BOS Scoring hatte, T0 alles anderen.

Das Ganze Wird dann auf Ertrag pro Block umgerechnet und ergibt eine APR rate aliquot für die Mietdauer umgerechnet.

Channel Duration

Die Mietdauer von 2016 Blöcken also 2 Wochen ist ein Standard wert in der GUI kann der nicht verändert werden (zumindest bis jetzt)

sie bestimmt die Vertragsdauer, die der Hersteller/Maker (ASK Order) und der Abnehmer/Taker (Bid Order) eingeben, wenn sie vom Auktionator abgeglichen werden. Dies bedeutet, dass der Hersteller die angebotene Liquidität mindestens für die ausgewählte Anzahl von Blöcken bereitstellen muss. Der Hersteller darf den Kanal nicht vor Ablauf der vereinbarten Mietdauer schließen. Der Hersteller kann den Kanal nach Ablauf der Dauer schließen, ist jedoch nicht dazu verpflichtet. Wenn ein Kanal wirtschaftlich ist, können weitere Routing-Gebühren erhoben werden, wenn der Kanal offen bleibt.

LightningPool Info Channel Diese Telegram Channel sendet regelmäßig ausgeführte Orders.

Lösung 5: Bots und andere Dienste die noch kommen oder es schon gibt und man nichts weis.

@LightningLiquidityBot Auch ein Service um Seine Liquidität zu verkaufen der Bot handhabt die Zahlung mit KeySend.

image

Adaption und freie Gedanken meiner Seite:

Nun Abschließend ein paar Gedanken zum Thema Onboarding und Zugang. Weil man jetzt immer öfter hört. Es wird immer schwieriger Onchain TX günstig zu machen neue die hinzukommen können sich das nicht leisten usw.

Wenn man den 2nd Layer als Dienstleistung sieht und auch annimmt und ja, die kann auch zentraler organisiert sein, mal mit mehr oder weniger Vertrauen einher gehen, wird es immer Entitäten geben die ins Geschäft kommen wollen. Wie so soll es nicht interessant sein für jemand eine Kanal zu dir zu öffnen, genau so wie dir jetzt die Bank eben eine Kreditkarte anbietet. Und als Gegenleistung eben die Onchain Fee hat.

Zusätzlich noch das Interesse den Kanal lange zu betreiben um nicht zu früh wieder Schließkosten zu haben. Und so bekommt man die Möglichkeit LND Zahlungen anzunehmen ohne hohe Initialisierungsaufwand. Und Das ist nur ein Beispiel ich, ich kenne auch schon jemanden der bietet Onboarding mit Fiat DCA an.

Die Power der Dezentralisiertet liegt nicht darin das unbedingt jedes Individuum dezentral agieren muss sondern das es eine Gegenkraft zu Zentralen Einheiten gibt (was bis jetzt undenkbar war) Und Individuen sich auf ein faires und transparenteres monetäre System verlassen können, egal welche granuläre Einheiten dann drauf abgebildet oder verschoben werden.

Es liegt in der Natur der Sache das Early adopters eine Vorteil haben in dem sie Risiken eingehen und das gilt ja nicht nur für Bitcoin. Das verhält sich meiner Ansicht nach auch proportional um so früher desto höher das Risiko. Und so ehrlich muss man sein, eine Portion Glück gehört manchmal mal auch dazu.

Das heißt um vielleicht mal eine andre Perspektive darzulegen. Zu spät? Wofür ? Ja um dem nächsten satoshi Stack oder 100x pump Nachzulaufen möglicherweise, um Sich mit dem Space zu befassen, zu lernen zu experimentieren ? Bei weitem nicht. Ich sehe es als Investment, meine Zeit, das Lernen und das Verstehen und Benutzen der verschiedenen Wehrzeuge. Irgendwie oder wann wird dieses Wissen von Wert sein der vielleicht auch in satoshi beglichen wird.

Ein Chinesisches Sprichwort Lautet:

mögest du in interessanten Zeiten leben!“

und das tun wir, definitiv.


Quellen:

:zap:Welcome to our Lightning Wiki​:zap: - ION Lightning Network Wiki

lightningwiki.net

LND Overview and Developer Guide

Blog | Lightning Labs

Introduction - Lightning Pool

Till it’s lightning-fast — Uncover the Lightning Network Transactions | by Y. | Medium

Lightning Node Management - Lightning Node Management

Let’s keep the fees low | Starting the Lightning Network Fee Market | by David Coen | Coinmonks | Medium

Jameson Lopp :: Articles

1ML - Lightning Network Search and Analysis Engine - Bitcoin mainnet

Lightning Network Explorer

Mit BTCPay Lightning Zahlungen akzeptieren

Bitcoin Wiki

Tip me;-)


LNURL1DP68GURN8GHJ7MRWW3UXYMM59E3XJEMNW4HZU7RE0GHKCMN4WFKZ7URP0YLH2UM9WFHXZMT984D82MN00QY60VNH

52 „Gefällt mir“

Besten Dank für diese Erleuchtung! Lightning ist wahrlich eine Welt für sich, in die man erst einmal eintauchen muss, um sich zurecht zu finden.

  • Das Gebührenset muss man bei jeder Kanalöffnung selbst definieren, richtig? Habe noch nirgends eine Einstellung zu den Standard-Gebührenset gesehen.
  • Die Schließungsgebühren kann man gar nicht abschätzen, oder? Ich meine, das hatte @Hodl auch mal angesprochen.

Schöne Zusammenfassung! Was mir noch unklar ist: Wenn ich Inbound-Liquidität durch Überweisung an meine mobile Wallet erzeuge, wie sorge ich dafür, das ich dafür einen bestimmten Kanal aus meiner „Sammlung“ verwende?

Als ergänzender Hinweis: Die Base-Fee ist bei einigen sehr großen Nodes (z.B. LNBIG) kleiner als 1 Sat eingestellt.

1 „Gefällt mir“

@osito

Standardwerte werden in der lnd.conf definiert.

[Bitcoin]
bitcoin.active=1
bitcoin.node=bitcoind
bitcoin.mainnet=1
bitcoin.feerate=199
bitcoin.timelockdelta=144

lnd.conf Example
lnd.conf Example - alle Parameter

der lnd services muss neu gestartet werden

Bei einem cooperative close kann man die fee schon angeben, die GUI scheint da default werte zu nehmen. Und das timing im mempool spielt immer eine rolle eh logisch.

https://api.lightning.community/#closechannel

bei einem forced close kommt die ComitFee ins Spiel

Beim öffnen eines Channels wird auch eine bestimmte menge für closing kosten hinterlegt (wird übrigens von der channel balance abgezogen) Ich bin mir noch nicht sicher ob dieser wert sich an die aktuelle fee rate anpasst und das Commit Weigt lässt sich angeblich nach dem öffnen eines Kanales anpassen. Und es passiert beim closing noch eine 2te TX die hat man nicht so wirklich unter Kontrolle und hat etwas mit der LockTime zu tun. Hier muss ich mich noch genauer reinfuchsen.

@Hodl Du kannst den ausgehenden Kanal ja angeben

3 „Gefällt mir“

Bei Umbrel geht das offensichtlich nicht. Ich nehme an, du meinst Raspiblitz oder RTL?

RTL oder Thunderhub oder auf der shell lncli. Ich kenn das UI von Umbrel leider nicht. Ich denke solche GUIs müssen vorsichtig sein welche settings sie anbieten wird sicher noch eine weile dauern bis man die volle Kontrolle über die GUI bekommt. lässt sich RTL nicht auf Umbrel installieren ?

Ja danke, habe RTL jetzt installiert!

@mrsieb Die geänderte Werte in lnd.conf werden dann aber bei jedem Update von RaspiBlitz, bzw. LND (bei mir derzeit 0.11.1-beta) überschrieben, oder?

nein die liegt im LND Data Folder auf der Festplatte.


Der Folder wird ja zur Wiederherstellung nach dem Upgrade verwendet, ohne channels schließen zu müssen. Bei RaspiBlitz is der update Prozess denkbar einfach.

Abgesehen davon ist es kein Weltuntergang sich die lnd.conf gesondert noch aufzuheben so oft ändert man die dann auch nicht.

Bei umbrel ist das noch so. Die Konfigdateien werden beim Update überschrieben. Daher ssh rein, Kopie erstellen, Update machen, Änderungen nachziehen.

@mrsieb Vielen Dank für die super hilfreichen Tipps!

Hi,
wäre nett wenn ihr mir zwei(Anfänger-) Fragen zum Thema Lightning beantworten könntet!

  1. Zahlungen können nur zwischen den beiden peers eines channels laufen, korrekt?
    → Zahlungen an einen Dritten funktionieren nur sofern einer der beiden Peers mit genanntem Dritten einen separaten channel eröffnet hat?

  2. Wenn ich einen Channel mit einem Peer eröffne (welcher keinen Channel zu mir eröffnet) und keine Transaktionen an mich sendet, sind meine Bitcoin/satoshis auf der Blockchain zum Peer übertragen worden und ich habe diese BTC nicht mehr, richtig?

  1. Ja oder wenn du anderweitig über n Hops mit dem Ziel verbunden werden kannst.
  2. Richtig.

Zu 2) hätte ich auch noch eine Verständnisfrage. Wenn ich dein Beispiel verwende, aber keine Zahlung im Sinn habe, sondern Routing zur Verfügung stellen möchte, dann „spende“ ich sozusagen mein eingesetztes Guthaben für Zahlungen anderer? Schließe ich diesen Channel ohne, dass ich ein Rebalance durchführe, verliere ich sozusagen meinen Einsatz im Lightning Netzwerk?

Danke für deine Antwort.

Dann lohnt sich die Eröffnung eines Channels eigentlich nur, mit einem gut Vernetzten Peer, um somit Zahlungen tätigen zu können, oder?

Würde ich so sehen. Um möglichst gut vernetzt zu sein, müsste man die großen Netzwerke anzapfen: ACINQ, LNBig, bCyber :wink: etc. oder direkt eine Verbindung mit der Shop-Node eröffnen.

Also diese Frage muss ich mit nein beantworten. Viel mehr hast du deine Bitcoins auf der Blockchain in ein „Gemeinschaftskonto“ übertragen über das du und dein Peer verfügen könnt. Ihr tauscht dann untereinander nur noch die Informationen aus wem wieviel Guthaben von diesem Konto gehört.

1 „Gefällt mir“

Nein, du spendest nichts. Wenn du Routing im Lightning Netzwerk betreibst ist das (abgesehen von den Gebühren die du verlangen kannst) ein Nullsummenspiel. Auf einem Channel zu einem Peer verschiebt sich die Balance zu dir, auf einem anderen Channel verschiebt sich die Balance in gleicher Höhe zu einem anderen Peer. Am Ende hat sich der dir zustehende Anteil an Bitcoins nicht verändert.

2 „Gefällt mir“

Danke für die Erklärung! Hatte jetzt noch keinen channel close ohne, dass Zahlungen darüber geflossen sind.

Sowohl beim Layer 1 Bitcoin, als auch beim Layer 2 Lightning ist alles Trustless aufgebaut. Das heißt du musst deinem Peer nicht vertrauen um Transaktionen ausführen zu können oder wie bei Lightning deinen Channeleinsatz zurück zu erhalten. Ich hab es mit dem „Gemeinschaftskonto“ nur stark vereinfacht dargestellt, wenn sich aber dein Peer zu viel aus dem Topf nehmen will, kann man ihn bestrafen indem man sich die gesamte Balance aneignet. Da wurden im Protokoll die meisten Szenarien die eintreten können auch bedacht.

Moin, ich versuche gerade eine Channel auszugleichen. In RTL findet er keine Route, deswegen hier in ThunderHub. Angeblich ist die Fee zu hoch, siehe rote Ausschrift. Das kann ich mir aber nicht vorstellen. Eingetragen waren übrigens 470000 Sat die wieder zurük zu mir sollten.
Damit waren m.E. die maximale Summe die durch einen Kanal passt nicht überschritten. Was macht man denn da noch falsch ?

Vermutlich machst du gar nichts falsch, ich weis alle würden gern über due GUI arbeiten aber leider agiert man da noch etwas blind. Ob RTL oder TH der Vorgang ist ja der selbe.

Also zu einen is da noch ein stelle mehr drin es es sind 4,7M sat die passen, das limit is aber sekundär das betrifft die HTLCs und auch beim wumbo protokoll is das hin fällig. Also die 470K die du versucht hast zu balancen, sind von der Menge her absolut kein Problem. Eine Route zu haben die 470k durchschieben kann schon viel eher. Ja hier kommst auf die Vernetzung der Nodes an. Und die höhe der Gebühr die man bereit ist zu Zahlen.

Zum einen dürfte das noch eine ältere TH Version sein (0.12.7) is aktuell das sieh das interface etwas anders aus. Welche maximal Fee hast du bei dem Vorgang eingestellt? Max Fee ? stell da mal 200 Sat ein und versuch es nochmal.

Auf der CLI mit BOS hat man mehr Kontrolle und man bekomm auch Fehler.

bos@raspberrypi:~ $ bos rebalance --help

 bos rebalance

 Change the liquidity profile of two peers

 When specifying amount you can use formulas or *k *m for *1e3, *1e6

 Specifying target liquidity you can use CAPACITY/2, other formulas

 You can use tags with --avoid, --in, --out

OPTIONS

 --amount <amount>                  Maximum amount to rebalance                 optional
 --avoid <pubkey>                   Avoid forwarding through node               optional
 --avoid-high-inbound               Avoid rebalancing when inbound is high      optional      default: false
 --in <pubkey_or_alias>             Route in through a specific peer            optional
 --in-target-outbound <amt>         Balance up to outbound amount               optional
 --max-fee <max_fee>                Maximum fee to pay                          optional
 --max-fee-rate <max_fee_rate>      Max fee rate to pay                         optional
 --minutes <minutes>                Time-out route search after N minutes       optional
 --no-color                         Mute all colors                             optional      default: false
 --node <node_name>                 Node to use for payment request check       optional
 --out <pubkey_or_alias>            Route out through a specific peer           optional
 --out-channel                      Lock outbound rebalance to channels         optional      default: false
 --out-target-inbound <amount>      Balance up to inbound amount                optional

Beispiel:

bos@raspberrypi:~ $ bos rebalance --amount 10000 --in 02c16cca44562b590dd279c942200bdccfd4f990c3a69fad620c10ef2f8228eaff --out 02004c625d622245606a1ea2c1c69cfb4516b703b47945a3647713c05fe4aaeb1c --max-fee 20

err:

  • 400
  • LowRebalanceAmount
  • min: 50000

err:

  • 400
  • FailedToFindPathBetweenPeers

Mein Tipp versuch es mal mit kleineren Beträgen 10k schritten, und erhöhe die Max Fee.

Als Routing node brauchst schon einig Channels mit mehr als 3M um vernünftig „agieren“ zu können. mit zu kleinen Channels gerät das routing schnell ins stocken. Abgesehen davon das die Comit Fee im Verhältnis zum Channel Volumen relativ viel belegt.

Local: 13535
Remote: 16319
= 29854 Sat die aktuell bewegt werden können
29854 + Comit Fee 20146 = Channel Size 50k

So sieht das übrigens aus wenn ein wenig leben in den Node kommt.

Und So beim ordentlich viel aktivität

2 „Gefällt mir“