Sind kleine Zahlungen im Lightning-Netzwerk überhaupt sicher?

Das Lightning-Netzwerk ist besonders beliebt für Zahlungen mit kleinen Beträgen. Doch funktionieren diese überhaupt ohne Vertrauen?

5 „Gefällt mir“

An dieser Stelle muss ich unbedingt ein grosses Kompliiment an den Blocktrainer und sein Team loswerden: Die Tiefe und Kompetenz in den technischen Beiträgen finde ich hervorragend!! :slight_smile:

Zum beschriebenen Szenario:
Wenn Oscar sein Recht durchsetzt, d.h. seine Sats trotz der höheren Gebühren von Alice zurückholen will, muss er doch den Kanal zwischen sich und Alice schliessen. Damit verliert Alice nicht nur Reputation im Netzwerk sondern eben auch einen Zahlungskanal. Und ein solcher ist aufgrund der Transaktiosgebühren eben mehr „wert“ als die Sats, die sie nicht bezahlen will. D.h. sie verliert letztlich auch finanziell.
Oder habe ich da etwas falsch verstanden?

3 „Gefällt mir“

Danke, freut mich! :slight_smile:

Genau, die Schließung des Kanals geht damit einher.

In der Regel ist das so. Es ist eben ein theoretischer Gedankengang. Ein böswilliger Akteur, der bereit ist Ressourcen auszugeben, könnte durchaus solche kleinen Zahlungen sabotieren und damit quasi einen Denial of Service durchführen. Fraglich ist natürlich wie oft bzw. wie lange.

Was die Transaktionsgebühr betrifft: Der „Ersteller“ des Kanals übernimmt diese bei einem non-cooperative close, d.h. der Angriff macht nur dann Sinn, wenn es sich dabei auch um das Opfer selbst handelt. Ansonsten würde sich Alice in unserem Beispiel natürlich komplett ins eigene Knie schießen. Du hast natürlich recht damit, dass sie das ohnehin schon tut, da sie einen Zahlungskanal und ihren guten Ruf verliert.

Der HTLC kommt dann eben zusätzlich als Output obendrauf, für den Oscar in unserem Beispiel zahlen muss. Um es mal komplett durchzudenken, muss Oscar also im schlimmsten Fall:

  • Die eigentliche Transaktionsgebühr der Schließung zahlen (müsste er sowieso – also kein Problem)

  • Für den zusätzlichen HTLC Output zahlen (was sich durch den geringen Wert eigentlich nicht lohnt)

  • Und was ich im Beitrag nicht erwähnt habe: Der HTLC Output ist wiederum ein neuer UTXO in Oscars Wallet, also wieder ein kleiner, unökonomischer Output, der in Zukunft evtl. teuer ausgegeben bzw. konsolidiert werden muss.

Je nachdem könnte Oscar also nicht nur den Betrag des HTLC effektiv verlieren, sondern noch obendrauf zahlen. Und je höher die Gebühren im Netzwerk, desto effektiver ist dieser Angriff (da sich die Grenze nach oben schiebt).

1 „Gefällt mir“

Viele Dank für diese ausführliche Antwort!

Hmm, das ist für mich noch nicht ganz klar. So eine Tx ist doch erstmal eine 2x2 MultiSig, d.h. beide sind Ersteller. Ich meine aber, vor einigen Jahren mal gelesen zu haben, dass ‚aktuell‘ jeweils nur eine Partei den Kanal „finanzieren“ kann, d.h. nicht z.B. beide Seiten mit je 1 BTC. Ist das noch so? Dann wäre natürlich klar, wer Ersteller ist.

Wie genau meinst Du das? Also quasi für die zusätzlichen Bytes des Outputs? Also wenn es ein non-cooperative close ist, signiert ja Alice nichts mehr. D.h. Oskar müsste - wenn die Gebühren der bestehenden Tx nicht reichen - diese per RBF oder CPFP bezahlen, oder?

Hab’s aber schon so verstanden :wink: Also Oscar bezahlt ggf. mehr Gebühr für die Tx, die den Kanal schliesst und dann eben noch, um den HTLC Output zu holen…oder ehen nicht, weil dieser in diesem Szenario ja weniger Wert ist als die Gebühren.

Ist jetzt vielleicht etwas Offtopic, aber das ist schon länger eine Befürchtung bzw. ein Kritikpunkt von mir an Lightning:
Das LN könnte eben zentralisiert werden, wenn eine Tx, also das Erstellen des Kanals wirklich sehr viel (z.B: 1000.- aufwärts) kostet.

  1. Können es sich nur noch grössere Teilnehmer leisten, diese Gebühr vorzuschiessen (und danach mit Routing zurückzuverdienen) und 2. können es sich die Kleinen dann nicht mehr leisten, Kanäle eben durch solche DOS Agriffe oder simple Bedienfehler zu „verlieren“.
    V.a. wenn (wie oben vermutet) derjenige die Tx Gebühren zahlen muss, der die Liquidität in den Kanal bringt. Denn das ist ja in der Regel eher der Kleine, also der Kunde, der über LN Geld ausgeben will. Aber selbst WENN die Gebühren in Zukunft z.B. von beiden Seiten bezahlt würden. Einem Techgiganten macht es nichts aus, den Kanal zu schliessen und 500.- zu verlieren, dem kleinen Benutzer aber schon. => Man könnte Zahlungen zensieren, wenn sich nicht jeder „beliebig“ oft das Eröffnen eines Kanals leisten kann. („Bei fehlendem Impfnachweis wird der Kanal geschlossen“)

Würde mit Cross Input Signature Aggregation das Dust Problem nicht verschwinden da es sich dann wieder rechnet solche Beträge über die Chain einzufordern in dem man eine Multiparty Transaktion baut?

@tmlc
Interessante Frage:
Verschwinden würde das Problem aber mMn nicht, denn Du musst ja in der Tx, in der Du den Dust ausgibst, alle diese vielen kleinen Inputs dennoch referenzieren mit Tx ID und Index des Outputs. Das Internet hat mir soeben gesagt:

Transaction IDs are alphanumeric strings which are all 64 characters long.

D.h. wenn ein Dust-Input weniger Wert ist als 64*[x Sats/Byte Tx Gebühr] würde das Problem für diesen weiter bestehen.

Abgesehen davon: falls ich das im LN richtig verstanden habe, müsstest Du ja beim oben beschriebenen Angriff von Alice rechtzeitig reagieren. Wenn Du dann keine anderen Dust Tx hast, die Du auch geich aufsammen kannst lohnt es sich auch nicht.