wenn ich den Thread mal für eine artverwandte Frage kapern dürfte ^^
Habe beim lesen des öfteren aufgeschnappt das ein zeitlicher geringer Anpassungsintervall von z.B. unter einer Stunde, Probleme bei der Informationsweitergabe deiner Fee-Anpassung an die anderen Nodes durchs Gossip führen kann.
Daher Frage ich mich welcher cronjob Intervall zum Anpassen der Fees so Standart ist.
Grüße
p.s.: Einordnung der Größenverhältnisse und Intension meiner Node.
Meine Node erfüllt derzeit den Zweck einer kleinen Routing Node, dient aber primär dafür meine privaten Zahlungen in jede Ecke der Welt mit lnd abwickeln zu können.
Mein vorhaben ein kleines Tool zu schreiben, welches die Vorteile von Charge-lnd und rebalande-lnd kombiniert, wurde mit LNDg umgesetzt. Das Tool ist nicht von mir.
Hier wird genau das gemacht, was ich mir vorgestellt hatte, dass die Fee Rate bei Inaktivität verringert und bei viel Aktivität erhöht wird, um den optimalen Mittelwert zu finden.
Edit:
Rebalance-lnd ist, wenn man keine Fee Rates ändern will immer noch gut zu gebrauchen.
Ich hatte den charge-lnd Entwicklern mein Vorschlag damals präsentiert. Dieser wurde abgelehnt.
Das Tool wurde jetzt schon seit einigen Monaten nicht mehr geupdatet aber die Fee Rate Update Strategie dieses Tool taugt sowieso nichts, weil man entweder zu billig oder zu teuer ist.
Macht es eigentlich mehr Sinn viele kleine Channels aufzumachen oder sollte man lieber wenige große Channels aufmachen?
Also wenn ich das richtig verstanden habe, muss man große Channels von mindestens ein paar Mio. Sats aufmachen, um ein wirklich gescheiter Routing Knotenpunkt zu sein.
Weil man sonst als kleine Node der Grund für fehlschlagende Transaktionen ist, was dann wiederum dazu führt dass die eigene Node als Route einer Transaktion möglichst vermieden wird.
(Beziehe mich auf folgendes Video:⚡️ Bitcoin Lightning Network Channel Size... SIZE MATTERS! - YouTube)
Hab ein kleines Problem mit meiner Lightning Node…
Ich wollte mir letztens über Bitrefill einen Amazon Gutschein kaufen (ca. 70€).
Hab dann die Invoice von Bitrefill gescannt aber meine lightning Transaktion ging mehrmals nicht durch (Fehlermeldung:no route).
Beim 4. Mal funktionierte es dann endlich.
Zur Info:
Hab nur 2 Channels offen:
einmal ca. 230€ zu Bitrefill Routing (Bitrefill Routing • LightningNetwork+)
und einmal ca. 5€ zu einem Freund (Test Channel)
Ich bin eig. davon ausgegangen, dass es passen würde wenn man einen Channel zu einer sehr großen Node offen hat.
Weil gerade funktionieren Zahlungen nicht besonders zuverlässig und nur sehr langsam (zumindest Bitrefill, woanders noch nicht getestet)
Sollte ich vielleicht mein Channel zu „Bitrefill Routing“ schließen und direkt zu der größten Bitrefill Node einen Channel aufmachen (Bitrefill • LightningNetwork+)?
Oder brauch ich einfach mehrere Channels zu großen Nodes?
Ich will nur eigentlich möglichst wenig Geld auf meiner Lightning Node liegen haben…
Hallo zusammen,
ich habe drei kleinere Channels (2x 100,000 out und 1x 100,000 in) zu meinem Node. Am Anfang blieb mein Lightning-Kontostand gleich. Seit einiger Zeit beobachte ich, dass sich der Stand verändert obwohl ich nichts bezahle oder Zahlungen erhalte. Zuerst nahm der Stand zu und jetzt gehen fast tgl. ca. 500 sats ab.
Wie kommt das? Es kann doch nicht sein, dass sich ein Kontostand verändert!
@OrangedWatson
Ich würde mindestens 1 weiteren Kanal mit einer gut angebundenen Node (und mit fairen Gebühren) eröffnen. Bitrefill ist bzgl. Gebühren nicht gerade bescheiden (eine Node berechnet Gebühren immer beim Weiterleiten, also wenn die Funds in einem Kanal von outbound zu inbound wechselt) und obwohl man meinen könnte, dass ein Kanal zu Bitrefill dafür sorgt, dass man dann „direkt“ mit Bitrefill verbunden ist und keine Gebühren beim Kauf eines Gutscheins zahlt, ist das nicht so.
@Camper
Du scheinst irgendeine Automatisierung (auto balancing) aktiviert zu haben (Autopilot?). Guck dir deine Konfiguration an und deaktiviere es.
Das sind Commit Fees, die je nach aktuellem Mempoolstand ausgehandelt werden und als Closing-Fees reserviert werden. Bei geringem Mempool sind Veränderungen kaum zu spüren, in letzter Zeit jedoch „sieht“ man die Schwankungen deutlicher, vor allem bei kleineren Kanälen.
Bei mir das gleiche. Wenn das Commit Fees sind, schwankt es dann auch wieder nach oben wenn diese niedriger werden? Sind bei mir fast 5000 Sats über Nacht gewesen?!
Vielen Dank für die links, jedoch wird beim stackexchange link nichts von der dynamischen Änderung gesagt. Beim libreddit link wird von einem user diese Dynamik beschrieben, aber auch nicht technisch erläutert (eine Antwort enhält einen link auf dieselbe stackexchange Quelle).
Also, die commit fee wird ja verwendet, um im Fall eines Force-Closes die on-Chain Gebühren hierfür zu bezahlen. Bei jeder Zahlung, die über den jeweiligen Channel abgewickelt wird, wird eine neue commit transaction gegenseitig gebaut, signiert und an den Channel Partner übertragen, um für den Fall der Fälle ohne Zutun des Channel Partners den Channel schließen zu können. Es ist natürlich logisch, dass bei jeder neuen Zahlung die aktuellen on-chain Gebühren einkalkuliert werden müssen (inklusive zusätzlicher Reserve, da man nicht weiß, wie es sich in Zukunft entwickelt, wenn eventuell eine Force-Close Transaktion notwendig wird). LND scheint hierfür aber mittlerweile eine Reserve aus dem on-chain Wallet zu nehmen (Anchor Commitments), sodass die angezeigte Lightning-Balance konstant bleiben müsste. Was ich mich allerdings frage: Was passiert, wenn das gelockte Guthaben durch ein Anchor-Commitment nicht mehr ausreicht?
Mittels max-commit-fee-rate-anchors wird eine maximale fee rate festgelegt bis zu der die Commit Fee angehoben werden kann. Diese ist bei LND mit einem Defaultwert von 10 s/vb angegeben, was im derzeitigen Mempool-Umfeld zu wenig ist. Wenn die Commit Fee für den nächsten Block nicht ausreichen sollte, gibt es im besten Fall die Anchors (bei Anchor Channels), die dazu verwendet werden, die TX per CPFP zu bumpen und die effective fee rate beider TXs anzuheben.
Allerdings ist ein CPFP teuerer als wenn die Force Close TX direkt mit der Commit Fee passen würde. Daher ist es günstiger die max-commit-fee-rate-anchors in Zeiten eines volatilen und hohen mempools entsprechend anzuheben und mehr Spielraum für einen erfolgreichen Broadcast im Falle eines Force Closes zu haben.
Kannst du mir eine große Node vorschlagen mit fairen Gebühren?
Mein Problem war nämlich auch noch, dass bei vielen Nodes die Minimum Channel Size mehrals 0,01btc ist und ich würde mir wenn dann noch ein Channel mit ca. 150-200€ aufmachen
Die LNBiG Nodes sind meist sehr fair, haben aber glaube ich auch eine hohe Minimum Channel Size. 1M sats würde ich aber ruhig reinstecken, überleg dir das (ist ja nur gelocked und nicht weg, solange du es nicht ausgibst). Wenn die on-chain Gebühren wieder ansteigen, wirst du dich über zu kleine Kanäle ärgern.
Am besten guckst du dir auf amboss.space große Nodes an und guckst, mit wem sie so verbunden sind und wie der Fee Report (Outgoing) ist.
Wohl dem der das ganze noch versteht. Das ist nichts mehr für „Normalsterbliche“. Wie soll das jemals von der Allgemeinheit verstanden und benutzt werden?
Das muss in Zukunft vermutlich auch nicht mehr verstanden werden. Heute müssen Parameter, die Abhängigkeiten von Mempooleigenschaften (wie Gebühren) haben, manuell eingestellt werden. Zukünftig wird das durch automatisiertes Überwachen des Mempools selbst geschehen.
