danke für die Rückmeldung. Das freu mich. Dann fehlt noch min eine interessierte Person für das Projekt.
Die Idee wäre man einigt sich auf eine Channelgröße bsp. 200k. Dann eröffnet Person A zu Person B, Person B zu Person C und Person C zu Person A einen Channel. Anschließend wird im gleichen Kreislauf über einen Rechnungsausgang die halbe Channelgröße abzgl. Fees (dann ca. 90k) geschickt. So hat jeder anschließend 50:50 als Local und Remote Balance.Hierbei gehört etwas vertrauen dazu, da wir uns hier in einem öffentlichen Forum bewegen und uns hier „öffentlich“ verabreden hat man zumindest eine gewisse Verbindlichkeit. Man kann die Rechnungsrunde auch noch in 2-3 Teilbeträge aufteilen dann hat man das Risiko weiter minimiert.
Ich würde mich freuen wenn sich noch eine Person meldet, dann könnten wir das Projekt starten. Bitte meldet euch. Gerne mache ich auch mehrer Runden mit bzw. machen wir die Runde mit Person D … größer.
Verständnisfrage: Warum sollte Person C noch einen Channel zu Person A öffnen? Die Erreichbarkeit C → A wäre über die Kette bereits sichergestellt, oder?
Gute Frage. Eigentlich geht es bei der Verbindung C zu A darum, dass jeder am Schluss dann einen Channel mit bsp 200k Local und Remode Balance hat. Weiterhin kann man sich die von mir genannte Rechnungsrunde zuerst auch sparen. Da jeder zu Beginn die 200k Inbound und outbound Liqudität hat. Die Runde a->b->c->a kann man dann Nutzen um ein rebalancing durchzuführen.
Der Zweck ist eine Rebalcing dreieck zu haben, also den möglichst kürzesten weg zu haben. Es braucht nur eine Person das rebalacing durch führen über 50% der balance im idealfall sind dann alle in der kette ausgeglichene balance. Um am Routing prozess teil zu haben braucht natürlich jeder node seine eigen weiteren inbounds und outbounds zu anderen peers.
Um so mehr solche dreicke man herstellen kann desto leichter tut man sich mit dem rebalancing. Die erfüllen „nur“ diesen Zweck.
Kann man das Rebalancing so steuern? Um Fees zu sparen würde das Routing Abkürzungen (unbekannte Dritte) nehmen, wenn vorhanden. Die Kette sollte auch relativ klein sein und möglichst wenige Verzweigungen bieten.
Also bildlich gesprochen:
Ketten:
A → B → C → D → E → A
B → F → A
Rebalance: A → B → F → A
Was ist den wenn man das Lightning Netzwerk Wabenförmig aufbaut? Hat man dadurch Vorteile?
Was passiert technisch wenn man nur in eine Richtung mit einer Note ne Verbindung aufbaut? Bringt das was und wo liegen die Unterschiede?
@Roadrunner Wenn man LN visualisieren würde, wäre es sowieso wabenförmig. Keine Node hat nur eine Verbindung zu einer zentralen Instanz (wenn sie nicht als Käufer auftritt, der nur einen Shop bedient). Eine Verbindung ist zudem nie einseitig. Eine Verbindung (Channel) hat immer Eingangs- und Ausgangskapazität und wenn diese beidseitig ausgeglichen ist, ist ein Senden und Empfangen auf beiden Seiten möglich.
Wenn du einen Channel erstellst, hast du zunächst nur deine ausgehende Kapazität reingesteckt. Das sieht dann so aus:
In diesem Zustand können Zahlungen durch deine Node nur rausgehen an die verbundene Partnernode. Das Rebalancing sorgt dafür, dass Kapazität für eingehende Zahlungen geschaffen wird. Dies sähe dann in etwa so aus:
Im Optimalfall sollten die Kapazitäten die gleiche Höhe (Summe) aufweisen, also im Verhältnis 1:1 stehen, um optimal routen, also Zahlungsströme durch deine Node fließen lassen zu können.
Genau!
Nach der Channeleröffnung könntest du also eine Zahlung durchsenden. Dieser Betrag steht dann auf der Receive oder Empfangsseite der Verbindung (Max Receive), erhöht also entsprechend die Empfangskapazität. So verschieben sich beim Routing immer wieder die Verhältnisse durch Zahlungen, die durch deine Node fließen. Diese Ungleichgewichte gilt es möglichst im Gleichgewicht zu halten, sonst kann deine Node wegen fehlender Kapazität nicht mehr routen.
Da wir aber nicht endlos Satoshis haben, um die Kapazitäten durch einseitige Zahlungen zu verschieben, gibt es das Rebalancing, also eine Zahlung an sich selbst zu schicken. Hier wird eine Route durch das Lightning Netzwerk gesucht, bei der einerseits der Empfangskanal einer Verbindung, andereseits ein Ausgangskanal einer zweiten Verbindung (also deine lokale Balance) erhöht wird.
Als Beispiel hier zwei Channels:
Ich würde also in diesem Beispiel versuchen, Satoshis über die untere Verbindung rauszusenden und über die obere Verbindung wieder zu empfangen. Ich rebalance also outgoing/Max Send (unten) und incoming/Max Receive (oben) mit einer bestimmten Summe, hier z.B.: 100.000 sats
Danke @osito für die Ausführungen. D.h. diese Re-Channels sind absolut sinnlos, weil kein Routing statt finden kann, da entweder local oder remote 0 Sats bleibt?
In diesem Beispiel müsste ich im unteren Channel eine Zahlung tätigen um meinen erstellten Channel zu balancen. Mein Re-Channel Partner könnte das selbe machen das die eingesetzten Sats wieder ausgeglichen sind und unsere Channel auch als Routing Channel fungieren können? @Goldsucher04 wollen wir das testen?
Re-Channels sind zwar möglich, aber wohl nicht so vorgesehen bzw. unnötig für die Funktion von LN. Routing kann dennoch passieren, aber zunächst nur über getrennte Verbindungen: Empfangen nur über den Remote-Kanal von deinem Node-Partner (in deinem Bild obige Verbindung), Senden nur über den selbst-initiierten Kanal (unten).
Das Problem fängt aber im Rebalancing an:
In Thunderhub kann ich beispielsweise gar nicht auswählen, welchen Channel (von zwei Channels mit demselben Partner) ich balancen will. Hier wird einfach eine „2“ und die Summe der Kapazitäten angezeigt. Daher kann ich gar nicht sagen, was bei einem Rebalance einer Doppelverbindung passiert bzw. welcher Kanal gewählt wird. Ein bisschen russisch Roulette an dieser Stelle. Bei RTL kann ich zumindest den Outgoing- bzw. Sende-Kanal manuell auswählen.
Dazu folgender Prozess zwischen zwei Nodes A und B mit einer Zielverbindung über 2M Sats:
A und B fügen sich gegenseitig als Peers hinzu (geht mit RTL, noch keine Channel-Eröffnung)
A sendet B eine Rechnung (invoice) über die Hälfte der avisierten Channelsumme: 1M
B bezahlt über Lightning diese Rechnung (Gebühren werden abzogen)
A eröffnet nach Zahlungseingang den Channel mit B mit 2M Sats
A sendet die Hälfte der Summe über den geöffneten Channel (1M) an B, um die Balance von ca. 1:1 zu erreichen (abzgl. Gebühren)
Zu 4 und 5.: Dieser Schritt wird über einen Befehl ausgeführt. Wie dies über RTL oder Thunderhub funktioniert (ohne bspw. eine neue Rechnung, die B stellen und A zahlen müsste, ist mir noch nicht schlüssig).
@mrsieb Bitte um Korrektur/Ergänzung, falls ich das falsch verstanden habe.
Die on-chain Gebühren für die Channeleröffnung sollten hierbei so gering wie möglich gehalten werden (whatthefee.io), die Verbindungserstellung (+ Risiko eines Force Close + Schließung) sollte als Dienstleistung verstanden werden.
Weitere Vorschläge von openoms:
Minimum 1M Kapazität
0,02% Provision für Verbindungsersteller
Einigung über die Routing Fee (z.B. 100ppm)
Einigung über die Lebensdauer der Verbindung (z.B. Minimum 1 Monat)
Du bist ein Engel. Momentan bin ich nicht in meiner Heimat. Werde dich wenn ich darf mit Fragen Löchern wenn ich wieder Zuhause bin um die Lightning endlich in Betrieb zu nehmen
Ich verstehe das nicht ganz. Ich habe bei mir Channels stehen wo das beidseitig sich schon geschehen ist.
Ich dachte das die eigenen Channels nur zum senden und die anderen zum „empfangen“ sind also das es in beide Richtungen geht. Und das dann halt mit höchstens der Balance womit diese erstellt wurden.
Ist doch eigentlich quatsch das man dann noch was machen muss damit alles perfekt ist, ist doch viel zu aufwendig?
Unabhängig von dem Ziel Dreieck- oder Wabenstrukturen zu bauen bin auch an ganz normalen Kanalpartnern interessiert.
min.500k und längerfristig
kieselblitz1 1ML-Link
IPv4 0293a4a5933422fa7cae2c8ff4c44490f26cf3dd7ac02b826ee20d4cba7dac944d@91.109.21.148:34939
oder
TOR 0293a4a5933422fa7cae2c8ff4c44490f26cf3dd7ac02b826ee20d4cba7dac944d@24iisahq44obgie75vmtdxtwvgbe2g7a3wk7ylpayclgbkqck5uypiqd.onion:9735
kieselblitz2 1ML-Link
TOR 02c0248895195c1c069d48608057f9e493df21460e71d0e7238a0672ef3e99f8d3@2ezlumnftl5ddggozvicih2bx4ct72jn4zw3bce6z6ivi5b4cjza6lqd.onion:9735
