Warum kann ein zwischengeschalteter Lightning-Knoten nicht (fast) alle Gebühren übernehmen?

Stellen Sie sich eine Blitzzahlung vor: Alice möchte Dave 100 Sat über zwei Zwischenstationen zahlen: Alice – Bob – Charlie – Dave. Sowohl Bob als auch Charlie werben mit einer Gebühr von 2 Sat. Alice sendet 104 sat an Bob und erwartet, dass er 102 sat an Charlie weiterleitet. Aber Bob leitet nur 101 Sat weiter. Dann hat Charlie die Wahl: entweder die Zahlung fehlschlagen und nichts bekommen, oder sie für nur 1 Sat weiterleiten. Es scheint, dass die wirtschaftlich vernünftige Wahl ist, trotzdem weiterzuleiten. Wenn das stimmt, warum nehmen First Hops dann nicht immer fast alle Gebühren für sich selbst?

Aufgrund des Onion-Routing weiß Bob natürlich nicht, ob Charlie der letzte Hop ist. Wenn Charlie der endgültige Empfänger ist und er nicht die erwartete Summe erhält, wird er das Urbild nicht preisgeben, und Bob wird nichts bekommen. Aber können solche Strategien über viele Versuche hinweg im Durchschnitt profitabel sein?

Antworten (3)

Sicher, es könnte etwas Spieltheorie im Spiel sein, aber zwei Dinge sprechen dagegen:

  1. Bob weiß nicht, wie hoch die Gebühr oder der endgültige Zahlungsbetrag ist. Natürlich konnte er eine fundierte Vermutung anstellen. Aber vielleicht war die letzte Zahlung 101,5 Sats und Charlie sollte für 500 msat weiterleiten. Charlie müsste jetzt sogar 500 msat hinzufügen, um ihre 101,5 amt zu erfüllen, um weiterzuleiten.
  2. Es ist derzeit anders implementiert. Knoten werden einfach nicht weiterleiten, wenn der Betrag, den sie erhalten, abzüglich des Betrags, den sie weiterleiten sollen, unter ihren Gebühren liegt. Wenn Bob also mit den Zwiebeln herumspielen würde, würden spätere Knoten derzeit automatisch mit einer unzureichenden Gebühren-Fehlermeldung ausfallen. Dies könnte natürlich für Denial-of-Service-Angriffe missbraucht werden.
1. Kann Bob Charlie nicht einfach nach seinem Honorar fragen? 2. "Knoten würden derzeit automatisch ausfallen" - aktuelle Implementierungen tun das, aber dies kann nicht erzwungen werden, oder?
Bob könnte Charlie fragen, aber da Bob nicht weiß, wie lang die Route ist, sind die gegebenen Informationen niedrig, aber sie könnten verwendet werden). Es gibt also Möglichkeiten. Und ja, ich sehe keine Möglichkeit, dieses Verhalten zu erzwingen
no bob würde den amount_to_forword für den nächsten Hop nicht ändern, sondern einfach einen anderen Betrag weiterleiten, als in seinem Teil der Zwiebel angegeben war. Dies hätte keine Auswirkungen auf HMACs, aber offensichtlich ist das Einmischen / Verletzen des Protokolls eine schlechte Idee, da Charlie wahrscheinlich die Zwiebel scheitern würde / sollte, da Charlies Routing-Gebühren nicht ausreichen
@RenePickhardt Ich habe das gerade herausgefunden und meinen früheren Kommentar gelöscht. Was für ein tadelloses Timing :). Das tut mir leid

Bei jedem Hop entlang der Route wird der volle Betrag einschließlich Gebühren mit einem neuen HTLC gesendet, und im Zwiebelpaket wird ihnen mitgeteilt, wie viel davon an den nächsten Hop weitergeleitet werden soll. fee_insufficientSie können daher feststellen, ob für die von ihnen angekündigten Gebühren für ihren eigenen Knoten genug bereitgestellt wird, und wenn die Gebühr nicht ausreicht, können sie den HTLC einfach entfernen, ohne ihn weiterzuleiten, indem sie einen Fehlercode an den vorherigen Knoten in der Route zurücksenden.

Es gibt eine mögliche Rennbedingung, bei der sich die Gebühren geändert haben, sodass die neueste channel_updatezusammen mit dem Fehler weitergeleitet wird fee_insufficient, sodass der Zahler die Route mit aktualisierten Gebühren erneut versuchen kann.

Jeder HTLC ist bedingt durch den Empfang von payment_preimageoder Zeitüberschreitung. Derzeit wird dasselbe Preimage für jeden Hop entlang der Route verwendet, was die Zahlung von Alice an Bob davon abhängig macht, dass Dave das Preimage an Charlie freigibt, der es dann an Bob weiterleiten kann, der es dann an Alice weiterleitet.

Wenn der vorletzte Knoten versucht, weniger als den beabsichtigten Betrag an das Zahlungsziel weiterzuleiten, antwortet das Zahlungsziel mit dem Fehlercode incorrect_or_unknown_payment_details, wodurch auch der HTLC entfernt wird. Jeder Knoten entlang der Route leitet dann denselben Fehler weiter und löscht jeden HTLC, und kein Geld wechselt den Besitzer.

"Wenn die Gebühr nicht ausreicht, können sie den HTLC einfach entfernen" - aber müssen sie das ? Sicher, wenn der letzte Knoten weniger bekommt als erwartet, schlägt das Ganze fehl. Die Frage war, wenn ich meine Gebühr als X ankündige und eine weitergeleitete Zahlung mit Gebühren <X angeboten bekomme, warum sollte ich sie fallen lassen, anstatt wenigstens etwas zu verdienen?
Die Node muss es nicht fallen lassen, aber wenn sie nicht mindestens den angeforderten Betrag an die nächste Node weiterleiten, ist es sehr wahrscheinlich, dass die Zahlung fehlschlägt und sie sowieso nichts verdienen. Es ist unwahrscheinlich, dass ein Knoten zunächst Zahlungen mit unzureichenden Gebühren sendet, da er höchstwahrscheinlich fehlschlagen wird.

Zusammenfassend, was ich in anderen Antworten und anderswo gelesen habe: Ja, ein Knoten kann dies technisch tun, aber dies wäre wahrscheinlich nicht wirtschaftlich, da bei aktuellen Implementierungen eine Zahlung fehlschlägt, ist der Unterschied zwischen "eingehenden" und "ausgehenden" Beträgen geringer als ihre angekündigte Gebühr. Unter der Annahme, dass der Großteil des Netzwerks nicht bösartige Software ausführt, wird die Zahlung mit modifizierten Gebühren wahrscheinlich fehlschlagen. Die genaue wirtschaftliche Analyse dieses Angriffs (und des damit verbundenen DoS-Angriffs) wurde jedoch nicht durchgeführt (AFAIK).

Warum kann ein zwischengeschalteter Lightning-Knoten nicht (fast) alle Gebühren übernehmen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v