Von BOLT 02 können wir lernen
Wenn ein Knoten Änderungen für das Remote-Commitment hat, kann er sie anwenden, die resultierende Transaktion signieren (wie in BOLZEN #3 definiert) und eine
commitment_signedNachricht senden.1. type: 132 (`commitment_signed`) 2. data: * [`channel_id`:`channel_id`] * [`signature`:`signature`] * [`u16`:`num_htlcs`] * [`num_htlcs*signature`:`htlc_signature`]
Warum reicht die Unterschrift für die gesamte Verpflichtungstransaktion nicht aus? Ich verstehe, dass jeder HTLC seine eigene Signatur in der HTLC-Erfolgstransaktion hat htlc_pubkeyund daher auch benötigt, aber was war der Grund für dieses Design?htlc_secret
Warum reicht die Unterschrift für die gesamte Verpflichtungstransaktion nicht aus?
Weil das htlc_signatureFeld die Signatur für die HTLC-Transaktionen enthält , die aus der/den htlc-Ausgabe(n) (entweder empfangen oder angeboten) der Commitment-Transaktion ausgegeben werden.
Um ein wenig zu erweitern, einige Pfade der HTLCs-Skripte (Zeitüberschreitung für eine angebotene HTLC-Ausgabe und Erfolg für eine empfangene HTLC-Ausgabe ) zahlen zu einer 2von2, daher benötigen Sie die richtige Transaktion, die von dieser Ausgabe ausgegeben wird, um signiert zu werden, bevor Sie sich dazu verpflichten ( andernfalls nicht auszugeben, wenn dieser Skriptpfad verwendet wird) ausgegeben.
BEARBEITEN: Diese Frage stammt aus dieser Github-Ausgabe , zu der Olaoluwa Osuntokun (@Roasbeef) heute eine detaillierte Erklärung auf hoher Ebene gab, warum HTLCs der zweiten Stufe in Lightning Network verwendet werden.
Das Folgende ist die Kopie seiner Antwort, die für jeden, der vorbeikommt, von Interesse sein könnte.
Hier ist mein Versuch einer Erklärung auf hohem Niveau:
Wir verwenden in dem System sogenannte zweistufige HTLCs. Dies ermöglicht es uns, den CLTV (absolute Zeitsperre für HTLCs) vom CSV (Commitment Delay to Allow for Retribution) zu entkoppeln. Um zu sehen, warum dies ein Problem ist, überlegen Sie, ob wir beide im HTLC-Skript der obersten Ebene hatten. Von hier aus kann man sich ein Szenario vorstellen, in dem wir einen HTLC haben, der zeitlich begrenzt werden kann (absolute Blockhöhe bestanden), aber wir können ihn nicht ausgeben (Zeitüberschreitung), bis unser CSV-Zeitraum ebenfalls abgelaufen ist. Daher müssen die CSV-Werte auch unter Berücksichtigung des absoluten Timelock-Werts (CLTV) eingestellt werden. Entscheidend ist, dass ein Benutzer auf diesen CSV-Zeitraum warten muss, bevor er seinen eingehenden Off-Chain-HTLC stornieren kann (Zeitüberschreitung des ausgehenden On-Chain). Wenn der CSV jedoch größer ist als das Timelock-Delta (Unterschied zwischen eingehenden und ausgehenden HTLCs),
Ohne HTLCs bedeutet die Abhängigkeit zwischen dem CLTV-Deltawert und dem CSV-Wert, dass, wenn man einen höheren CSV-Wert haben möchte (mehr Zeit, um böswillige Kanalkollegen zu bestrafen), sie auch einen längeren CLTV-Deltawert haben müssen. Als Beispiel ist eine übliche Einrichtung mit lnd so, dass wir für Kanäle mit sehr hohem Wert einen CSV-Wert von 2016 Blöcken (zwei Wochen) haben. Ohne HTLCs der zweiten Ebene müssten wir auch unseren CTLV-Deltawert (40 Blöcke Standard atm) größer als 2016 Blöcke machen. Diese Änderung würde sich dann durch das gesamte Netzwerk ausbreiten, was zu sehr langen Sperrwerten führen würde. Der Absender eines HTLC frisst die Sperrverzögerung für die gesamte Zeit, was bedeutet, dass er weiß, dass sein absoluter Worst Case viel höher ist, und sich gegen eine bessere Multi-Hop-HTLC-Sicherheit eintauscht.
Glücklicherweise haben wir dafür eine Lösung gefunden: zweistufige HTLCs. Beachten Sie, dass die oben beschriebenen HTLC-Skripte nie wirklich eingesetzt wurden. Zweistufige HTLCs werden tatsächlich aus einem ähnlichen Grund im ursprünglichen LN-Whitepaper verwendet. Das oben beschriebene fehlerhafte Design entstand, als Entwickler versuchten, die Skripte und den On-Chain-Footprint ein wenig zu komprimieren.
Ein zweistufiger HTLC entkoppelt die CSV-Periode von dem eigenen CTLV-Zeitverriegelungs-Delta. Um dies zu tun, verlangen wir jetzt von der Partei, die die Schließung erzwungen hat, ihre HTLC mit einer speziellen Transaktion auszugeben. Diese Transaktion gibt eine CLTV-Klausel im Skript aus und enthält selbst auch einen nLocktime-Wert. Die Ausgabe dieser speziellen Transaktion zahlt dann an die Partei, die den HTLC zeitlich festlegt oder einlöst, erzwingt dann aber eine CSV-Periode. Wir nennen sie zweistufig, da wir zwei Zustände im Anspruch durchsetzen: auf absoluten Timeout-Wert warten, dann auf CSV-Wert warten. Beachten Sie, dass die Partei die ursprüngliche HTLC-Ausgabe ausgeben kann, sobald der absolute Timeout-Wert abgelaufen ist, und die HTLC-Beanspruchungszustandsmaschine in die CSV-Wartezeit überführt. An diesem Punkt können sie alle Off-Chain-HTLCs sicher stornieren, da die andere Partei zu diesem Zeitpunkt nicht in der Lage ist, sie mit einem Pre-Image zu begleichen.
Die Art und Weise, wie wir diese Ausgaben durchsetzen, besteht darin, dass wir alle HTLC-Ausgaben aus der eigenen Commitment-Transaktion (die Sie während eines erzwungenen Abschlusses übertragen) tatsächlich zu einer Multi-Sig-Ausgabe machen. Wir verwenden diese Ausgabe, um im Wesentlichen eine „Off-Chain-Multi-Sig-Vereinbarung“ zu erstellen. Da sie unsere Unterschrift benötigen, um diese Ausgabe auszugeben, zwingen wir sie mit vorsignierten Transaktionen zu einer bestimmten Art von Ausgaben. Infolgedessen senden wir jedes Mal, wenn wir ihnen eine neue Zusage geben möchten, zusätzlich zur Zusageunterschrift (Mehrfachsignatur, die den Finanzierungsoutput ausgibt), auch eine Reihe von Unterschriften, eine für jeden HTLC, die ihre Ausgaben segnen HTLC-Ausgabe.