Verständnigfrage: Lightning Netzwerk und Confirmation im Falle von Betrug

Hallo zusammen,
Vielleicht auch im Hinbllick auf das angekündigte Lightning Video (ich freue mich schon darauf) habe ich eine Frage etwas technisch/mathematischer Natur, aus reiner Neugier. Vielliecht habe ich aber auch etwas am Protokoll missverstanden.

Mein Verständnis ist, dass man im LN bilaterale Kanäle eröffnet, die wie eine Art Prepay-Kreditkarte aus der BC über ne Transaktion initial gefüttert werden. Die beiden Peers einigen sich nun laufend darauf, wer momentan wieviel dieses Guthabens zugute hat, indem sie potentielle BC Transaktionen austauschen und gegenseitig signieren, die aber nicht an die BC geschickt werden, solange die Peers kooperieren. Sie einigen sich darauf, dass nur die jeweils aktuellste potentielle Transaktion genutzt werden darf, und die anderen ungültig seien (was sie aber aus Sicht der BC tatsächlich nie werden). Das wird dadurch umgesetzt, dass im Output Script dieser Transaktionen ein Timelock z.B. eines Tages für den Empfänger drin steht, aber mit einem Geheimnis des einen Peers kann der andere Peer den Output schon vorher beziehen. Durch gegenseitigen Austausch dieser Geheimnisse werden die alten Transaktionen daher für den Partner wertlos, denn der Andere kann den Betrag vor Ablauf des Tages selber ausgeben, und nur von der aktuellsten Transaktionen kennen die Peers gegenseitig die Geheimnisse nicht. Man kann also sagen, wenn ein Peer eine alte (für ihn günstigere) Transaktion des Kanals in betrügerischer Absicht an die BC schickt, hat der andere Peer die Möglichkeit, eine „Vergeltungstransaktion“ mit dem Geheimnis ebenfalls in BC zu legen, um den Betrag früher ausgeben zu können. Jede dieser Transaktionen kommt zuerst in den Mempool, so dass der Betrogene die relevante Transaktion schon sehen kann, bevor sie ihren Weg in die BC gefunden hat. Soweit so gut, und auch eine elegante Lösung.

Das Problem sehe ich aber u.A. dann, wenn es die Vergeltungstransaktion nicht rechtzeitig in die BC schafft, weil die BC im Moment überlastet ist, resp. die Transaktionen irre doch sind (eventuell höher als der Betrag, um den es geht). Da wäre es doch praktisch, wenn die Vergeltungstransaktion schon im Mempool ihre Wirkung entfalten könnte, zumindest, solange die erste Transaktion noch nicht bestätigt wurde… also so in der Art: „Akzeptiere keinen Block in der BC mit einer Transaktion, für die es im Mempool schon eine krypographisch passende Vergeltungstransaktion gibt“. Eine solche Logik würde im schlimmsten Fall einem Soft Fork entsprechen, da man ja strenger würde. Ist etwas in der Art vorgesehen, oder wie geht man mit dem Problem um? Ja, im Prinzip kann die initiale Betrugs-Transaktion schon bestätigt worden sein, dann wäre es dafür natürlich zu spät - aber die Gebühr dieser initialen Transaktion wurde ja schon lange im Voraus fixiert, der Betrüger kann sie also nicht seinerseits erhöhen, und so hätte diese selber es im Fall einer Überlastung schwer, bestätigt zu werden - was dem Betrogenen die Chance gäbe, sie noch im Mempool zu neutralisieren.

Mit child pays for parent kann man die Vergeltungstransaktion beschleunigen. Das macht die Vergeltungstransaktion natürlich noch teurer. [EDIT: Siehe Diskussion weiter unten, und Antwort von @mrsieb]

Die Gefahr, dass Vergeltung nicht effizient und damit weniger effektiv wird, sehe ich auch. Insbesondere, wenn der main layer relativ zu lightning noch teurer wird. Deine Idee klingt deshalb erstmal gut.

Problematisch an deinem Vorschlag ist, dass damit Transaktionen inhaltlich analysiert und beurteilt werden. An sich gültige Transaktionen würden durch ihren Kontext ungültig. Von da wäre es nur ein kleiner Schritt, Transaktionen auch aufgrund anderer Kontexte (Blacklists, Historie, etc.) zu zensieren, oder zumindest darüber zu diskutieren.

Sowas hat meiner Meinung nach nichts im main layer zu suchen. Die Regeln des main layer sollten nicht aufgrund einer Erfordernis eines second layer eingeschränkt werden. Erweitert ja (taproot, segwit), aber eingeschränkt nein.

Da die Transaktion des Angreifers ja trotzdem gemined werden kann, würde sich schlimmstenfalls ein Schwarzmarkt für solche Transaktionen entwickeln.

Hmm das mit CFPF wusste ich nicht. wäre ziemlich hässlich. Aber geht das wirklich? Im Output Script steht doch da normalerweise, dass der Betrüger die Transaktion erst nach einer Anzahl Blöcke (die z.B. einem Tag entsprechen), glaube mit „144 OP_CHECKSEQUENCEVERIFY“, ausgeben kann… Google meint, in CFPF müssten die beiden Transaktionen im gleichen Block gemined werden (wobei ich das nur gegoogelt habem, ich kannte CPFP bisher gar nicht), was ja ein Widerspruch wäre.

[EDIT] Ich bin mir gerade nicht sicher. Einserseits muss der Ausgabescript ja gar nicht sichtbar sein, falls er nur gehasht auftaucht (soll in taproot glaube ich eh default werden?), das würde meine Idee vom Mempool ja schon mal prinzipiell verunmöglichen, von deinen legitimen Einwänden mal ganz abgesehen… andererseits müsste zumindest die Ausgabetransaktion, der CPFP macht, diesen Script dann ja im Input aufzeigen und würde dann spätestens durch die Knoten als illegal abgelehnt, weil eben noch nicht 144 Blöcke vergangen sind, und damit auch die erste Transaktion neutralisieren. Bin mir aber echt nciht sicher, ob ich das noch korrekt durchblicke.

Das is ja mal eine Hardcore Frage, Ich bin mir nicht mal sicher ob ich deine Gedanken komplett folgen kann aber ist es nicht so das eine penalty Transaction durch die Zeitliche deterministik dann wieder alles rückgängig macht ? Und die Aufgabe übernehmen ja für gewöhnlich Watchtowers.

Ok Ich versuch das hier grad zu verstehen.

Each party has its own anchor output that locks to their funding key. This is to prevent a malicious peer from attaching child transactions with a low fee density to an anchor and thereby blocking the victim from getting the commit tx confirmed in time. This defense is supported by a change in Bitcoin core 0.19: https://github.com/bitcoin/bitcoin/pull/15681. This is also the reason that every non-anchor output on the commit tx is CSV locked.

1 „Gefällt mir“

Ich hab hier jetzt noch genauer nach geschaut:

Anchor Channels sind default nicht an:

lnd.conf

; The maximum fee rate in sat/vbyte that will be used for commitments of
; channels of the anchors type. Must be large enough to ensure transaction
; propagation (default: 10)
; max-commit-fee-rate-anchors=5

; If set, lnd will use anchor channels by default if the remote channel party
; supports them. Note that lnd will require 1 UTXO to be reserved for this
; channel type if it is enabled.
; protocol.anchors=true

Das jeder dieser Channels dann eine UTXO reserviert ist hald gewaltig nervig,
und zwing eine noch dazu die Hotwallet auf, ansonst kann man ja das funding von einer Coldwallet aus betreiben.

Des weiteren empfiehlt es sich externe adressen für das close comit anzugeben.

Noch eine Anmerkung: Dadurch, dass die Vergeltungstransaktion den gesamten channel leerräumt – also auch die Funds des Channel Partners, auf die man sonst kein Anrecht hätte, werden die höheren Gebühren (ggf. durch CPFP) für den Geschädigten überkompensiert.