Ein Hashed Time-Locked Contract kombiniert einen Hash und eine Zeitbedingung. In Lightning leitet jeder Hop einen HTLC mit Betrag, payment_hash und cltv_expiry weiter; Durch die Offenlegung eines passenden Vorbilds wird die Zahlung rückwärts über die Route abgeschlossen, während die Zeitüberschreitung die Teilnehmer schützt, wenn die Erfüllung nicht rechtzeitig eintrifft.
Der Absender arbeitet mit dem SHA-256-Zahlungs-Hash. Der Empfänger schließt die Zahlung ab, indem er ein Vorbild preisgibt, dessen SHA-256 genau mit diesem Hash übereinstimmt. Dasselbe Geheimnis bindet somit die atomare Abwicklung mehrerer Hops.
Jeder HTLC hat ein absolutes CLTV-Ablaufdatum. Wenn das Preimage nicht rechtzeitig eintrifft, müssen die Knoten über genügend Platz verfügen, um die Transaktion fehlschlagen zu lassen oder in die Kette zu pushen, bevor ihre Upstream-Verpflichtungen ablaufen.
Im normalen Lightning-Betrieb ist HTLC eine Kanalstatusänderung über update_add_htlc und anschließende Erfüllung oder Fehlschlag. Eine Bitcoin-Transaktion ist nur erforderlich, wenn der Kanal in der Kette erzwungen wird.
update_add_htlc enthält channel_id, id, amount_msat, payment_hash, cltv_expiry und onion_routing_packet. Peer prüft die Richtlinie und erstellt einen Folge-HTLC; Es kopiert das Eingabeobjekt nicht einfach blind.
Das Onion-Paket zeigt dem Hop nur die Informationen an, die für den nächsten Schritt benötigt werden. Der Knoten vergleicht die Menge und den ausgehenden CLTV mit der verschlüsselten Nutzlast, sodass er die Bedingungen überprüfen kann, ohne den gesamten Pfad zu kennen.
Der Weiterleitungsknoten erfordert ein späteres eingehendes Ablaufdatum als das ausgehende Ablaufdatum. Der Unterschied gibt Zeit, in der Kette zu reagieren, wenn der Downstream ein Vorbild erkennt oder kurz vor Ablauf der Frist ausfällt.
BOLT #3 schreibt angebotene/empfangene HTLC-Ausgaben in Commitment-Transaktionen mit Erfolgs- und Timeout-Zweigen. Die Skripte kombinieren Hash, Signaturen und Timelock so, dass das Ergebnis auch ohne Mitwirkung der Gegenpartei durchsetzbar ist.
Wenn die HTLC-Ausgabe nach Berücksichtigung der Gebühr unter den Staubschwellenwert der Transaktion fällt, kann sie aus den On-Chain-Ausgaben gestrichen werden. Aus diesem Grund behandelt BOLT #2 die Staubexposition als echtes Kanalrisiko.
Die Zahlung gelingt nur, wenn jeder Hop die Bedingungen akzeptiert und der Empfänger das Vorbild preisgibt. Liquidität, Gebührenlimits, Ablauflimits und Routing-Richtlinien können eine Zahlung lange vor der Konsensschicht von Bitcoin stoppen.
Überprüfen Sie update_add_htlc, eingehende/ausgehende Beträge und CLTV-Deltas und überwachen Sie Erfüllungs-/Fehlermeldungen. Dekodieren Sie zur Durchsetzung in der Kette die Commitment-Transaktion und den BOLT #3-Erfolgs-/Timeout-Pfad der HTLC-Ausgabe.
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, Payment Channel, Timelock, Kryptografischer Hash, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. Auf diesen Eintrag verweisen außerdem Timelock, Payment Channel, Lightning-Liquidität, Lightning Routing.