Moin,
mir wurde das Marktargument genannt, wonach sich #zerofee durchsetzen soll. Aber wie kann ich denn festlegen, dass er Basefee-Knoten meiden soll, auch weil die verdammt teuer sind, wenn man nur ein paar Sats verschicken will? Verschicke ich 10 Sats kommen 9 an. Ich wills billiger. Das muss doch konfigurierbar sein.
Grüße
Bei #zerobasefee geht es tatsächlich nicht um den Markt, sondern um die Technik.
Das Lightning Netzwerk ist so konzipiert, dass Zahlungen über eine unbekannte Route von LN-Kanälen geleitet werden.
Die Algorithmen zur Weiterleitung von Zahlungen sind derzeit auf niedrige Gebühren optimiert. Das bedeutet, dass Dutzende von Zahlungsversuche über verschiedene Routen unternommen werden müssen, bis eine Route erfolgreich ist oder die Anzahl der zu versuchenden Routen erschöpft ist. Dieses Verfahren ist sehr unzuverlässig und steht einer flächendeckenden Lightning-Adoption derzeit nicht ganz unwesentlich entgegen.
Daher spricht René Pickhard von „unreliable by design“. Derzeit ist diese Unzuverlässigkeit ein Kompromiss für die Privatsphäre. Die Unkenntnis der Channel Balances führt jedoch zu einem Brute-Force-Ansatz bei der Suche nach Zahlungsrouten. Dadurch wird das Netzwerk mit Zahlungsanfragen überlastet und es werden Anreize für Angriffe geschaffen, um die Kontostände aufzudecken.
René Pickhard hat einen Algorithmus für die Routenfindung entwickelt, der ein probabilistisches Modell für den Zahlungserfolg verwendet. Außerdem teilt er die Zahlung auf mehrere Pfade auf. Der Algorithmus funktioniert am besten, wenn die Base Fee der Kanäle Null ist. Mit anderen Worten, der Algorithmus berücksichtigt nur die Fee Rate.
An diesem Punkt setzt die #zerobasefee-Bewegung an, weil der Algorithmus aus technischen Gründen bislang Kanäle mit einer Base Fee > 0 ignoriert.
Nun zu deiner Frage mit den Gebühren:
Die Pickhard-Payment werden in jedem Fall teurer sein als traditionelle Lightning-Zahlungen. Der höhere Preis dient dem Zweck der maximalen Zuverlässigkeit der Zahlungen und damit auch einer höheren Zahlungsgeschwindigkeit.
Nach der bisherigen Routenfindung hast du keinen Einfluss darauf, wie die Zahlung von A nach B wandert. Du kannst vielmehr froh sein, wenn die Zahlung überhaupt ankommt, weil das System rein auf dem Prinzip von Trial and Error basiert.
Außerdem musst du berücksichtigen, dass neben der Base Fee ja noch die Fee Rate erhoben wird. Die wird in jedem Fall fortbestehen, weil die für die Pickhard-Payments unerheblich ist.
laut den github devs geht es um den markt xDDDD egal wo ich das geäußert habe die zerofee einfach mal festzuschreiben: „das regelt der markt“ … einfach nur dumm. wie soll er das wenn die voreinstellung die nicht zerofee variante vorgibt? kaum einer änderts es nach der installation selbst.
Die Implementierung in lnd-manageJ kann auch mit gesetzter Base Fee arbeiten. Je kleiner die Zahlungs-Stückchen sind, desto schlechter ist aber die Abschätzung (weshalb Kanäle mit Base Fee vergleichsweise selten berücksichtigt werden).
Das ist Quatsch. Im Papier wird sogar darauf hingewiesen, dass man die zu zahlenden Gebühren mit berücksichtigen kann (Faktor \mu). In lnd-manageJ ist das durch „fee weight“ realisiert, was bspw. beim „top up“-Feature zu sehr günstigen Zahlungen führt und sich bei mir im automatisierten Einsatz bewährt hat.