---
title: "Hash-Zeitvertrag (HTLC)"
description: "Ein HTLC macht eine Zahlung vor Ablauf mit einem Urbild einlösbar und danach über einen anderen Pfad erstattbar. So koordiniert es Zahlungskanäle und Atomic Swaps und kann dennoch scheitern."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Hash-Zeitvertrag (HTLC)

> Nur zu Bildungszwecken; keine Anlage-, Rechts- oder Sicherheitsberatung. Die Sicherheit eines HTLC hängt von den konkreten Skripten oder Verträgen, Kettenregeln, Bestätigungsrichtlinien, Gebühren, Überwachung und rechtzeitigem Handeln ab.

<a id="answer"></a>

## Direkte Antwort

Ein Hash-Zeitvertrag (HTLC) ist eine bedingte Zahlung mit zwei konkurrierenden Ausgabepfaden. Vor Ablauf kann der Empfänger einen Wert `x` offenlegen, dessen Hash dem gebundenen Wert `h = H(x)` entspricht, und die nötigen Signaturen oder Berechtigungen erfüllen. Danach kann der Zahler den Erstattungspfad nutzen. Die genaue Grenzordnung bestimmen Kette und Vertrag, nicht das Wort „vor“.

Der Hashlock verknüpft Handlungen: Wer nach einer ausgehenden Zahlung dasselbe Urbild erfährt, kann damit eine zugehörige eingehende Zahlung abrechnen. Der Timelock begrenzt die Bedingungsdauer. Zahlungskanäle leiten so Zahlungen weiter; Atomic Swaps koordinieren Übertragungen auf getrennten Systemen.

Ein HTLC ist nicht automatisch vertrauensfrei, atomar, privat oder selbsttätig. Es braucht korrekten Code, kompatible Hash- und Urbildkodierung, gestaffelte Fristen, Finalitätsannahmen, Gebührenzugang, Überwachung und rechtzeitige Bestätigung. Lightnings HTLC ist ein spezifiziertes Bitcoin-Design; andere Ketten können andere Semantik haben.

- **Hash-Zweig:** Urbild offenlegen und die Erfolgsberechtigung erfüllen, solange der Pfad gültig ist.
- **Zeit-Zweig:** Erstattungsberechtigung erfüllen, sobald die absolute oder relative Sperre gereift ist.

<a id="mechanism"></a>

## Funktionsweise

Bob wählt für eine Zahlung ein frisches, unvorhersagbares Urbild `x`, berechnet `h = H(x)` und gibt `h` an Alice. Alice sperrt Mittel nach Regeln, die `h`, Berechtigte und Ablauf `T` festlegen.

- Alice prüft vor Finanzierung Algorithmus, Bytekodierung, Betrag, Vermögenswert, Empfänger, Erstattungsziel, Kette und Ablauf.
- Bob prüft die tatsächlich finanzierte Ausgabe oder den bereitgestellten Vertrag statt Entwurf oder Oberfläche.
- Beim Erfolg liefert Bob `x`; die Logik prüft `H(x) = h` und die Berechtigung.
- Die Veröffentlichung oder Übermittlung von `x` kann Alice oder einem Vermittler die Abrechnung eines HTLC mit demselben Zahlungshash erlauben.
- Bleibt der Erfolg aus, wird die Erstattung bei `T` zulässig; sie wird dadurch weder gesendet noch bestätigt.
- Der Teilnehmer muss die richtige Transaktion bereithalten, ausreichend bezahlen, senden, Ersetzungen und Konflikte beobachten und Bestätigungen erhalten.
- Nach Offenlegung von `x` gegenüber Partei oder öffentlicher Kette gilt es als bekannt und darf nicht für fremde Bedingungen wiederverwendet werden.

Bitcoin unterscheidet absolute und relative Sperren. BIP 65s `OP_CHECKLOCKTIMEVERIFY` sperrt bis zu Blockhöhe oder Blockzeit aus dem Transaktions-Locktime; BIP 112s `OP_CHECKSEQUENCEVERIFY` bis zum nötigen relativen Alter einer Eingabe. Passende Transaktionsfelder sind ebenfalls nötig. Ein Timelock ist eine Validierungsregel, kein Planer.

In Lightning trägt `update_add_htlc` Betrag, `payment_hash` und `cltv_expiry`. Jeder Hop lässt sein ausgehendes HTLC vor dem eingehenden ablaufen, damit nach Erhalt des Urbilds Zeit für den Anspruch stromaufwärts bleibt. BOLT 3 definiert Commitment-Ausgaben, `HTLC-success`, `HTLC-timeout`, Signaturen, Widerruf, Dust-Kürzung und Verzögerungen; zwei Zweige allein sind kein vollständiger Kanal.

<a id="example"></a>

## Beispiel

Als Lehrbeispiel tauscht Alice `1 BTC` gegen Bobs `20 ETH`. Es zeigt nur die Reihenfolge; produktive Bitcoin- und Ethereum-Lösungen brauchen kettenspezifisch geprüften Code und dürfen diese Nennfristen nicht kopieren.

- Alice erzeugt frische `x` und `h = H(x)` und sperrt `1 BTC`, damit Bob per Urbild beansprucht und Alice nach `48 hours` erstattet.
- Nach Prüfung von Bitcoin-Transaktion und Bestätigungsrichtlinie sperrt Bob `20 ETH` mit kompatibler Kodierung; Alices Erfolg endet nach `24 hours`, danach folgt Bobs Erstattung.
- Vor Offenlegung von `x` für `20 ETH` prüft Alice Ethereum-Ketten-ID, Bytecode, Adresse, Vermögenswert, Betrag, Parteien, `h` und beide Pfade.
- Bob erfährt `x` aus Anspruch oder vereinbarter Nachricht und versucht den Bitcoin-Erfolg vor der späteren Frist.
- Stoppt der Tausch vorher, wird jede Erstattung nur nach ihrer Kettenregel zulässig und muss gesendet sowie bestätigt werden.

Der Abstand `48 hours` zu `24 hours` ist ein Reaktionspuffer, kein universeller Wert. Reorganisation, Blockzeit, Finalität, Ausführung, Relay, Mempool, Gebühren, Zensur und Betriebslatenz sind auf beiden Systemen zu modellieren. Der zweite Akteur darf nicht allein wegen „bestätigt“ in der Oberfläche fortfahren.

<a id="risks"></a>

## Risiken

- **Falsche Bindung:** Algorithmus, Länge oder Kodierung weichen ab, sodass dasselbe `x` nicht beidseitig gilt.
- **Falsches Artefakt:** Ausgabe, Ketten-ID, Adresse, Bytecode, Asset, Betrag, Empfänger oder Erstattung weichen von der Anzeige ab.
- **Unsichere Reihenfolge:** Gleiche oder zu enge Fristen verhindern den Anspruch stromaufwärts nach Zahlung stromabwärts.
- **Grenzfehler:** Blockhöhe, Blockzeit, Zeitstempel, relatives Alter sowie `<` und `<=` sind nicht gleich.
- **Keine Automatik:** Reife erlaubt nur die Ausgabe; Wallet, Node, Nutzer oder Wächter müssen handeln.
- **Gebühr und Dust:** Anspruch kann unwirtschaftlich, gekürzt, festgefahren oder ohne natives Gebührenasset unmöglich sein.
- **Bestätigung und Reorganisation:** Sichtbarkeit von Transaktion oder Urbild ist keine irreversible Abrechnung.
- **Wettlauf und Stau:** Erfolg, Timeout, Ersetzung, Konflikt oder Verzögerung verbrauchen den Puffer.
- **Implementierung:** Fehler in Skript, Vertrag, Wallet, Signatur, nonce, RPC oder Client können Pfade zerstören.
- **Überwachung:** Offline-Parteien können Offenlegung, Ablauf, Zwangsschluss, Ersetzung oder letzte Sendezeit verpassen.
- **Privatsphäre:** Wiederverwendete Hashes, Urbilder, Beträge, Zeiten und Kanalereignisse können Transfers verbinden.
- **Optionalität und Blockade:** Eine Partei kann Liquidität sperren und abbrechen; Abschluss und Entschädigung sind nicht garantiert.

Vor echtem Wert beide Pfade mit Kleinstbetrag testen, Artefakte und Fristen festhalten, Gebühren vorhalten und Überwachung sowie Sendung bei Ausfall zuweisen.

<a id="misconceptions"></a>

## Häufige Irrtümer

- **„Bei Ablauf kehrt das Geld automatisch zurück.“** Meist wird nur die Erstattung zulässig; sie muss gesendet und bestätigt werden.
- **„`H(x) = h` ist der ganze Vertrag.“** Signaturen, Zweige, Felder, Kettenregeln, Widerruf und Berechtigung zählen ebenfalls.
- **„Gleiche Fristen sind fair.“** Vermittler oder zweite Akteure brauchen nach Kenntnis von `x` Puffer stromaufwärts.
- **„Ein sichtbares Urbild garantiert Anspruchszeit.“** Bestätigung, Reorganisation, Stau, Gebühren und Zensur können sie aufzehren.
- **„Atomar heißt, beide Ketten ändern sich in einer unteilbaren Transaktion.“** Getrennte Zustände werden koordiniert; Abbruch, Erstattung und einseitige Zwischenstände bleiben.
- **„HTLCs sind anonym und beseitigen Vertrauen.“** Sie lecken Signale und hängen von Code, Ketten, Schlüsseln, Überwachung und Betrieb ab.

<a id="related"></a>

## Verwandte Themen

- [Kryptografischer Hash](/de/crypto/cryptographic-hash/)
- [MPC-Wallet](/de/crypto/mpc-wallet/)
- [Risiko von Multisignaturmodulen](/de/crypto/multisig-module-risk/)
- [Smart Contract](/de/crypto/smart-contract/)
- [State Channels](/de/crypto/state-channels/)

<a id="sources"></a>

## Quellen

- [BIP 65: OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BIP 112: CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals (abgerufen: 2026-08-20)
- [BOLT #2: Peer-Protokoll zur Kanalverwaltung](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs (abgerufen: 2026-08-20)
- [BOLT #3: Bitcoin-Transaktions- und Skriptformate](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs (abgerufen: 2026-08-20)
- [BOLT #4: Onion-Routing-Protokoll](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs (abgerufen: 2026-08-20)

Source: https://wiki.fcontext.com/de/crypto/htlc/index.mdx