Gibt es beim Eröfnen eines Channels einen „Mindestbetrag“?
Hallo, ich hätte Intresse einen Channel zu dir auf zu machen wenn ein Re Channel kommt. Für 100 bis 120k
Hi, hast du Lust Channels zu eröffnen für 100 bis 120k ?
Hi, bei einem Mehr-Eck Channel Projekt wäre ich zu haben. Gibt es noch eine genaue Beschreibung wie du das mit „zum balancing die Hälfte auf die Reise schicken“ meinst? Ist das eine normaler Rechnungsausgang? Für was genau wird das balancing benötigt? Bei meinen Channels wird bei local sowieso nur ca. die Hälfte der verwendeten Capacity angezeigt. Ist die andere Hälfte dann schon auf Reisen? Ein schönes Aufklärungsvideo von unserem @Blocktrainer wäre hierzu echt top! Die richtigen Infos durch Eigenrecherche zu erhalten scheint sehr fehleranfällig zu sein. Aber wir lernen ja gerne 
Wie lautet deine Adresse?
025c11a5446e082d23c437d81bbc08a1bb1411cf51e963424d05f635e8397f2c4b@cuoj7d5ro3padw4go34vuvlsnywbo3t3w2ybiemvxnsjvpd6vkpjgoid.onion:9735
Hey RTL,
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.
1 „Gefällt mir“
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
Moin Jungs*innen
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?
Lg Roadrunner
@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.
2 „Gefällt mir“
Ach… das bedeutet wenn ich mich mit deiner Note verbinde dann kann die Transaktion auch in beide Richtungen laufen? Hab ich das richtig verstanden?
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.
1 „Gefällt mir“
Aaaahhh… das bedeutet das erstmal was in die eine Richtung fließen muss, damit es auch später in die andere Richtung fließen kann?
Hab ich das jetzt verstanden? 
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
2 „Gefällt mir“
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?
1 „Gefällt mir“
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.
1 „Gefällt mir“
Die Lösung und das Ziel ist daher die Vermeidung von doppelten Verbindungen (Re-Channels). Die Methode ist hier beschrieben: https://openoms.gitbook.io/lightning-node-management/advanced-tools/balancedchannelcreation
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).
lncli openchannel <nodeID_of_A> --local_amt 2000000 --push_amt 1000000 --sat_per_byte 2
@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)
2 „Gefällt mir“