Hashed Timelock Contract łączy warunek hasha z blokadą czasową. Lightning używa payment_hash, kwoty i cltv_expiry dla każdego HTLC. Odpowiadająca payment_preimage umożliwia spełnianie warunków wstecz wzdłuż trasy; timeout pozwala na alternatywne rozliczenie. Bezpieczeństwo zależy także od potwierdzonych stanów kanałów, podpisów i reakcji na czas.
Odbiorca dostarcza 32-bajtową payment_preimage, której SHA-256 odpowiada payment_hash. BOLT 11 umieszcza hash w polu p faktury; sam hash nie ujawnia sekretu. Ta sama preimage łączy warunki kilku kolejnych HTLC. payment_secret z pola s jest inną daną i nie zastępuje preimage. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry]
Lightning cltv_expiry oznacza bezwzględną wysokość bloku, a nie znacznik czasu Unix ani okres ważności faktury BOLT 11 w sekundach. Po spełnieniu warunków czasowych może stać się dostępne wydanie przez timeout. Poprawna preimage nie przestaje jednak automatycznie działać; konkurencyjne wydania tego samego wyjścia nie mogą oba zostać potwierdzone w jednym poprawnym łańcuchu. Zwrot nie jest automatyczny. [BOLT 2 — Channel state and HTLC handling] [BOLT 11 — Payment hash and invoice expiry] [BIP 65 — CHECKLOCKTIMEVERIFY]
update_add_htlc proponuje dodanie, a update_fulfill_htlc lub update_fail_htlc obsługują spełnienie lub niepowodzenie. Sama wiadomość nie zamyka zmiany stanu: commitment_signed i revoke_and_ack zapewniają podpisy nowego stanu oraz unieważnienie starego po obu stronach. Zwykła płatność nie potrzebuje nowego zapisu w bloku, lecz finansowanie i zamknięcie kanału używają transakcji Bitcoina. [BOLT 2 — Channel state and HTLC handling]
Podstawę wiadomości update_add_htlc stanowią channel_id, id, amount_msat, payment_hash, cltv_expiry i onion_routing_packet. amount_msat jest wyrażone w millisatoshi. Węzeł sprawdza limity kanału, dostępną płynność i warunki przekazania; wychodzący HTLC ma własne parametry. Nie może zaoferować kolejnego HTLC, dopóki dodanie przychodzącego nie jest nieodwołalnie potwierdzone zgodnie z BOLT 2. [BOLT 2 — Channel state and HTLC handling]
Węzeł odszyfrowuje własną warstwę onion i weryfikuje jej integralność. Dla zwykłej niezaślepionej trasy porównuje amt_to_forward i outgoing_cltv_value z kwotą przychodzącą, opłatą i wymaganą różnicą czasu. Pakiet nie udostępnia mu całej trasy. Nie wyklucza to jednak korelacji ruchu ani innych sposobów wnioskowania o tożsamości; routing onion nie gwarantuje absolutnej anonimowości. [BOLT 4 — Onion routing and payload validation]
Przychodzący HTLC musi wygasać później niż kolejny wychodzący HTLC. Różnica cltv_expiry_delta daje pośrednikowi rezerwę na uzyskanie preimage, reakcję przy niedostępności drugiej strony i potwierdzenie w łańcuchu. Uwzględnia ryzyko opóźnień i reorganizacji; liczba bloków nie gwarantuje stałej liczby minut. Zbyt mała rezerwa zagraża środkom. [BOLT 2 — Channel state and HTLC handling]
BOLT 3 rozróżnia wyjścia offered i received oraz ścieżki HTLC-success i HTLC-timeout. Sama znajomość dowolnego hasha nie wystarcza: obowiązują odpowiednie podpisy, preimage i warunki czasowe. Lokalne wyjście drugiego etapu ma opóźnienie CSV to_self_delay, natomiast prawidłowy klucz unieważniający pozwala drugiej stronie użyć gałęzi karnej bez tego opóźnienia. Dokładny Script zależy od typu kanału. [BOLT 3 — HTLC transaction scripts and trimming] [BIP 112 — CHECKSEQUENCEVERIFY]
Jeśli kwota po odjęciu odpowiedniej opłaty drugiego etapu nie osiąga dust_limit_satoshis, transakcja commitment nie tworzy wyjścia HTLC. Reguły zależą od uzgodnionego typu: option_anchors i zero_fee_commitments nie mają tej opłaty drugiego etapu; zero_fee_commitments może skierować pominiętą wartość do shared_anchor. Nieistniejącego wyjścia nie można osobno dochodzić w łańcuchu. Suma takich HTLC tworzy dust exposure. [BOLT 3 — HTLC transaction scripts and trimming] [BOLT 2 — Channel state and HTLC handling]
Ten sam sekret wiąże warunki wzdłuż trasy, ale samo przyjęcie oferty nie gwarantuje zakończonej płatności. Płynność, liczba dostępnych HTLC, opłaty, terminy wygaśnięcia i reguły routingu mogą zatrzymać płatność. Bezpieczne spełnienie lub niepowodzenie wymaga prawidłowej kolejności zmian i rozwiązania na czas. Ujawnienie preimage nie jest tym samym co potwierdzenie transakcji Bitcoina. [BOLT 2 — Channel state and HTLC handling] [BOLT 4 — Onion routing and payload validation]
Porównaj przychodzące i wychodzące amount_msat, payment_hash i cltv_expiry; zweryfikuj preimage za pomocą SHA-256. Śledź także commitment_signed, revoke_and_ack i końcowy stan, a nie tylko jedną wiadomość fulfill/fail. Przy egzekwowaniu w łańcuchu zdekoduj rzeczywistą transakcję commitment, sprawdź istnienie wyjścia, używaną gałąź i HTLC-success/HTLC-timeout. Sprawdź podpisy, warunki czasowe i potwierdzenia; samo dekodowanie nie dowodzi poprawności. [BOLT 2 — Channel state and HTLC handling] [BOLT 3 — HTLC transaction scripts and trimming]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Lightning Network, Payment Channel, Timelock, Skrót kryptograficzny, CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY. Do tego hasła prowadzą również odsyłacze z Timelock, Payment Channel, Płynność Lightning, Lightning Routing.