HTLC steht für Hashed Timelock Contract. Gemeint ist eine bedingte Zahlung: Ein Weg verlangt einen geheimen Wert, dessen Hash, sein digitaler Fingerabdruck, dem vorher bekannten Wert entspricht. Ein anderer erlaubt die Rückholung, sobald Zeitbedingungen erfüllt sind. Der geheime Wert heißt preimage. Er ist kein Wallet-Passwort. Seine Kenntnis ersetzt keine erforderlichen Signaturen; Zeitablauf allein zahlt auch kein Geld zurück.
Anna möchte Pavel über das Lightning Network 20 000 sat schicken. Sat steht für Satoshi, die kleinste Einheit von Bitcoin auf der Blockchain. Die beiden haben keinen gemeinsamen Zahlungskanal, aber passende Verbindungen über Eva. Ein Kanal ist eine Vereinbarung zweier Teilnehmer über die Verteilung von Bitcoins. Sie lässt sich aktualisieren, ohne jede Zahlung neu in einem Block aufzuzeichnen. Eva bietet Pavel bedingt 20 000 sat an, Anna bietet Eva 20 010 sat. Die Differenz von 10 sat ist in diesem vereinfachten Beispiel Evas Gebühr. Zwei miteinander verknüpfte Kanalguthaben ändern sich; es reist nicht dieselbe einzelne Münze durch beide Kanäle. Pavel kennt ein Geheimnis, mit dem er seine Bedingung erfüllen kann. Eva nutzt denselben Wert anschließend gegenüber Anna. Sie muss Pavel also nicht allein auf sein Versprechen hin unwiderruflich bezahlen. Die Beträge veranschaulichen den Ablauf und sind keine übliche oder empfohlene Gebühr. [1]
Pavel bereitet für die Zahlung einen zufälligen geheimen Wert aus 32 Byte vor: die payment_preimage. SHA-256 berechnet daraus den payment_hash. Ob ein offengelegter Wert den richtigen Fingerabdruck ergibt, lässt sich leicht prüfen. Ein gut gewähltes Geheimnis allein daraus zurückzugewinnen, ist praktisch nicht machbar. Eine gewöhnliche BOLT-11-Rechnung, also eine Lightning-Zahlungsanforderung, enthält im Feld p den Hash und nicht die preimage. Erfüllt Pavel die Zahlung, läuft das Geheimnis entlang der Route zurück und verbindet die betreffenden HTLCs. Der payment_secret im Feld s ist etwas anderes: Er hilft dem Empfänger bei der korrekten Verarbeitung und ersetzt die preimage nicht. Keiner dieser Werte ist eine Seed Phrase (die Wörter zur Wiederherstellung des Wallets) oder der private Schlüssel des Wallets. [1] [4]
Hätten beide Zahlungen dieselbe Frist, könnte Pavel das Geheimnis so spät offenlegen, dass Eva ihren eingehenden Betrag nicht mehr beanspruchen kann. Deshalb läuft der von Anna eingehende HTLC später ab als Evas ausgehender HTLC an Pavel. Der Unterschied heißt cltv_expiry_delta und gibt Eva eine Reserve. Diese braucht sie auch, wenn eine Gegenpartei nicht mehr antwortet und die Vereinbarung mit Bitcoin-Transaktionen auf der Blockchain durchgesetzt werden muss. Die Reserve wird in Blöcken statt in exakten Minuten bemessen und muss Verzögerungen sowie Reorganisationen berücksichtigen. Software und Kanalregeln bestimmen ihre sichere Einstellung; zu wenig Reserve gefährdet die Mittel. Bei einer Reorganisation wird ein Teil der Kette durch einen anderen gültigen Zweig ersetzt; dadurch können sich frühere Transaktionsbestätigungen ändern. [1]
cltv_expiry bezeichnet in Lightning eine Blockhöhe, also die Position eines Blocks in der Kette. Es ist weder ein Unix-Timestamp (ein Zeitpunkt als Anzahl von Sekunden) noch die in Sekunden gemessene Gültigkeit einer BOLT-11-Rechnung. Sind die Zeitbedingungen erfüllt, kann der Timeout-Pfad eine Abwicklung ohne Geheimnis ermöglichen. Das Geld bewegt sich nicht von selbst: Die Lightning-Knoten, also die Programme zur Verwaltung der Zahlungskanäle, müssen die Kanaländerung korrekt abschließen oder die passende On-Chain-Transaktion verwenden. Auch eine gültige preimage wird durch Fristablauf nicht automatisch unwirksam. Ist derselbe Output, also ein Betrag mit Ausgaberegeln, noch nicht anderweitig ausgegeben, können zulässige Ausgabepfade miteinander konkurrieren; beide Ausgaben können nicht in derselben gültigen Kette bestätigt werden. Rechtzeitiges Handeln gehört deshalb zur Sicherheit. [1] [4] [5]
Ein HTLC verknüpft Bedingungen, macht aber nicht jeden Betrag auf jeder Route zahlbar. Eva braucht ausreichend Guthaben in ausgehender Richtung, also Liquidität, und Platz für einen weiteren offenen HTLC. Limits, Gebühren oder ein unerreichbarer Knoten können die Zahlung stoppen. Solange der offene Versuch nicht korrekt aufgelöst ist, kann ein Teil der Mittel gebunden bleiben. Der Wallet-Status beschreibt den gesamten Versuch; eine einzelne Nachricht reicht als Beleg nicht aus. Die Offenlegung einer preimage ist nicht mit der Bestätigung einer Bitcoin-Transaktion gleichzusetzen. Eine gewöhnliche erfolgreiche Lightning-Zahlung wird durch Kanaländerungen abgewickelt, ohne jede Zahlung neu in einem Block zu vermerken. [1] [3]
Die folgenden Abschnitte dienen als technische Referenz. Ein Kanalzustand hält fest, wem welcher Betrag zusteht und welche HTLCs noch offen sind. Eine Commitment-Transaktion ist eine signierte Bitcoin-Transaktion, mit der sich dieser Zustand auf der Blockchain durchsetzen lässt. update_add_htlc schlägt eine Ergänzung vor, update_fulfill_htlc meldet die Erfüllung und update_fail_htlc das Scheitern. Eine Änderung bloß anzukündigen reicht nicht. Über commitment_signed und revoke_and_ack tauschen beide Seiten Signaturen des neuen Zustands und Informationen aus, die eine sichere Verwendung des alten verhindern. Nach BOLT 2 müssen beide die betreffende Änderung unwiderruflich übernommen haben, bevor eine weitere Verpflichtung darauf aufbaut. Diese Einigung ist keine Blockbestätigung. Finanzierung und gegebenenfalls Schließung des Kanals stützen sich dagegen auf Bitcoin-Transaktionen. [1]
Felder sind einzelne Angaben einer Nachricht. Ein millisatoshi ist ein Tausendstel satoshi, eine Recheneinheit innerhalb von Lightning; auf der Bitcoin-Blockchain lässt sich dieser Bruchteil nicht separat ausgeben. Die Grundlage der Nachricht update_add_htlc bilden channel_id, id, amount_msat, payment_hash, cltv_expiry und onion_routing_packet. amount_msat ist in millisatoshi angegeben. Der Knoten prüft Kanallimits, verfügbare Liquidität und Weiterleitungsbedingungen; der ausgehende HTLC hat eigene Parameter. Der Knoten darf den nachfolgenden HTLC erst anbieten, wenn das Hinzufügen des eingehenden HTLC gemäß BOLT 2 unwiderruflich bestätigt ist. [1]
Onion-Routing verpackt die Anweisungen für jeden Vermittler in eigene verschlüsselte Schichten. Eva erhält die Angaben für ihren Schritt statt einer lesbaren Liste aller Teilnehmer. Der Knoten entschlüsselt seine eigene Onion-Schicht und prüft deren Integrität. Bei einer gewöhnlichen nicht verblindeten Route vergleicht er amt_to_forward und outgoing_cltv_value mit dem eingehenden Betrag, der Gebühr und dem erforderlichen Zeitabstand. Das Paket liefert ihm nicht die gesamte Route. Dies schließt jedoch weder Verkehrskorrelation noch andere Rückschlüsse auf die Identität aus; Onion-Routing garantiert keine absolute Anonymität. [3]
Ein Output ist ein Betrag mit Ausgaberegeln, die in der Sprache Script formuliert sind. Offered und received bezeichnen angebotene und empfangene HTLCs aus Sicht eines Kanalteilnehmers. Die zweite Stufe ist eine Folgetransaktion; CHECKSEQUENCEVERIFY (CSV) erzwingt eine Wartezeit ab der Bestätigung des ausgegebenen Outputs. Ein Revokationsschlüssel ermöglicht die Bestrafung eines veröffentlichten alten, bereits widerrufenen Zustands. BOLT 3 unterscheidet offered- und received-Outputs sowie die Wege HTLC-success und HTLC-timeout. Bloße Kenntnis irgendeines Hashes reicht nicht aus: Die entsprechenden Signaturen, die preimage und die Zeitbedingungen gelten. Der lokale Output der zweiten Stufe hat die CSV-Verzögerung to_self_delay, während der richtige Revokationsschlüssel der Gegenpartei den Strafzweig ohne diese Verzögerung erlaubt. Das genaue Script hängt vom Kanaltyp ab. [2] [6]
Trimming bedeutet, dass aus einem kleinen HTLC kein eigener Output entsteht, wenn der Kanalzustand auf die Blockchain gelangt. Dust bezeichnet solche kleinen Beträge. Dust exposure misst den Gesamtwert, der dieser Einschränkung ausgesetzt ist. Erreicht der Betrag nach Abzug der einschlägigen Gebühr der zweiten Stufe nicht dust_limit_satoshis, erzeugt die Commitment-Transaktion keinen HTLC-Output. Die Regeln hängen vom ausgehandelten Typ ab: option_anchors und zero_fee_commitments haben diese Gebühr der zweiten Stufe nicht; zero_fee_commitments kann den ausgefilterten Wert an shared_anchor leiten. Ein fehlender Output lässt sich nicht separat auf der Blockchain beanspruchen. Die Summe solcher HTLC bildet die dust exposure. [2] [1]
Die folgende Prüfung richtet sich an Knotenbetreiber und Entwickler. Dekodieren macht gespeicherte Angaben lesbar; es versendet nichts und beweist allein nicht, dass sämtliche Bedingungen erfüllt sind. Vergleiche eingehende und ausgehende amount_msat, payment_hash und cltv_expiry; prüfe die preimage mit SHA-256. Beobachte auch commitment_signed, revoke_and_ack und den endgültigen Zustand, nicht nur eine einzelne fulfill/fail-Nachricht. Bei der Durchsetzung auf der Blockchain dekodiere die tatsächliche Commitment-Transaktion, prüfe das Vorhandensein des Outputs, den verwendeten Zweig und HTLC-success/HTLC-timeout. Prüfe Signaturen, Zeitbedingungen und Bestätigungen; bloßes Dekodieren beweist keine Gültigkeit. [1] [2]
Für ein möglichst vollständiges Bild lies diesen Eintrag zusammen mit Lightning Network, Payment Channel, Timelock, Hash, CLTV, CSV. Auf diesen Eintrag verweisen außerdem Timelock, Payment Channel, Lightning-Liquidität, Lightning Routing.