HTLC

Anna chce wysłać Pawłowi 20 000 sat przez Lightning Network. Sat to skrót od satoshi, najmniejszej jednostki bitcoina w łańcuchu. Nie mają wspólnego kanału płatniczego, ale oboje mają odpowiednie połączenie przez Ewę. Kanał jest umową dwóch uczestników o podziale bitcoinów, którą można aktualizować bez zapisywania każdej płatności w bloku. Ewa oferuje Pawłowi warunkowe 20 000 sat, a Anna oferuje Ewie 20 010 sat. Różnica 10 sat to w tym uproszczonym przykładzie opłata dla Ewy. Są to powiązane zmiany sald w dwóch kanałach, a nie podróż tej samej pojedynczej monety. Paweł zna sekret pozwalający spełnić jego warunek. Ewa może następnie użyć tej samej wartości wobec Anny. Nie musi najpierw nieodwracalnie zapłacić Pawłowi, polegając wyłącznie na obietnicy. Kwoty ilustrują mechanizm, nie typową ani zalecaną opłatę. [1]

Paweł przygotowuje losowy sekret o długości 32 bajtów, payment_preimage. SHA-256 oblicza z niego payment_hash. Łatwo sprawdzić, czy ujawniona wartość daje właściwy odcisk; odtworzenie dobrze wybranego sekretu z samego odcisku jest praktycznie niewykonalne. Zwykła faktura BOLT 11, czyli żądanie płatności Lightning, zawiera hash w polu p, nie samą preimage. Gdy Paweł spełnia warunek płatności, sekret wraca wzdłuż trasy i wiąże odpowiednie HTLC. payment_secret w polu s jest inną wartością: pomaga odbiorcy poprawnie obsłużyć płatność i nie zastępuje preimage. Żadna z tych wartości nie jest Seed Phrase (słowami do odzyskania portfela) ani kluczem prywatnym portfela. [1] [4]

Przy takim samym terminie obu płatności Paweł mógłby ujawnić sekret zbyt późno, by Ewa zdążyła odebrać płatność przychodzącą. Dlatego HTLC od Anny wygasa później niż wychodzący HTLC Ewy do Pawła. Różnica cltv_expiry_delta daje Ewie zapas. Potrzebuje go również wtedy, gdy druga strona przestanie odpowiadać i umowę trzeba będzie wyegzekwować transakcjami Bitcoin w łańcuchu. Zapas liczy się w blokach, nie w dokładnych minutach, i musi uwzględniać opóźnienia oraz reorganizacje. Bezpieczne ustawienie wynika z oprogramowania i zasad kanału; zbyt mały zapas zagraża środkom. Reorganizacja zastępuje część łańcucha inną poprawną gałęzią, co może zmienić wcześniejsze potwierdzenia transakcji. [1]

W Lightning cltv_expiry oznacza wysokość bloku, czyli jego pozycję w łańcuchu. Nie jest znacznikiem czasu Unix (datą i godziną wyrażoną liczbą sekund) ani okresem ważności faktury BOLT 11 mierzonym w sekundach. Po spełnieniu warunków czasowych może otworzyć się ścieżka timeout, pozwalająca rozliczyć płatność bez sekretu. Środki nie przesuwają się same: węzły Lightning, czyli programy zarządzające kanałami płatności, muszą prawidłowo zakończyć zmianę kanału lub użyć odpowiedniej transakcji w łańcuchu. Poprawna preimage także nie przestaje automatycznie działać po terminie. Jeśli tego samego wyjścia, czyli kwoty z regułami wydawania, nie wydano już inaczej, dozwolone ścieżki mogą konkurować; oba wydania nie mogą potwierdzić się w jednym poprawnym łańcuchu. Reakcja na czas jest więc częścią bezpieczeństwa. [1] [4] [5]

HTLC łączy warunki, ale nie sprawia, że dowolna kwota przejdzie dowolną trasą. Ewa potrzebuje odpowiednich środków w kierunku wychodzącym, czyli płynności, i miejsca na kolejny oczekujący HTLC. Limity, opłaty lub niedostępny węzeł mogą zatrzymać płatność. Dopóki oczekująca próba nie zostanie prawidłowo rozstrzygnięta, część środków może pozostać zablokowana. Status portfela opisuje całą próbę; pojedyncza wiadomość nie dowodzi jej wyniku. Ujawnienie preimage nie jest potwierdzeniem transakcji Bitcoin. Zwykła udana płatność Lightning rozlicza się przez zmiany kanałów, bez zapisu każdej płatności w nowym bloku. [1] [3]

Dalsze części to dokumentacja techniczna. Stan kanału określa, komu przypada każda kwota i które HTLC jeszcze oczekują. Commitment transaction jest podpisaną transakcją Bitcoin pozwalającą wyegzekwować ten stan w łańcuchu. update_add_htlc jedynie proponuje dodanie; update_fulfill_htlc zgłasza spełnienie, a update_fail_htlc niepowodzenie. Samo ogłoszenie zmiany nie wystarcza. Za pomocą commitment_signed i revoke_and_ack strony wymieniają podpisy nowego stanu oraz dane, przez które użycie starego staje się niebezpieczne. Według BOLT 2 obie muszą nieodwołalnie przyjąć odpowiednią zmianę, zanim oprze się na niej kolejne zobowiązanie. Ta zgoda uczestników nie jest potwierdzeniem w bloku. Finansowanie i ewentualne zamknięcie kanału opierają się natomiast na transakcjach Bitcoin. [1]

Pola to poszczególne dane wiadomości. Millisatoshi jest tysięczną częścią satoshi, jednostką rozliczeniową wewnątrz Lightning; nie można osobno wydać takiego ułamka w łańcuchu Bitcoina. 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. [1]

Onion routing umieszcza instrukcje każdego pośrednika w oddzielnych zaszyfrowanych warstwach. Ewa otrzymuje dane potrzebne do swojego kroku, a nie jawną listę wszystkich uczestników. 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. [3]

Wyjście to kwota z regułami wydawania zapisanymi w języku Script. Offered i received oznaczają HTLC oferowany i otrzymany z perspektywy uczestnika kanału. Drugi etap to kolejna transakcja; CHECKSEQUENCEVERIFY (CSV) wymusza oczekiwanie od potwierdzenia wydawanego wyjścia. Klucz unieważniający pozwala ukarać publikację starego, już odwołanego stanu. 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. [2] [6]

Trimming oznacza, że mały HTLC nie staje się oddzielnym wyjściem przy przeniesieniu stanu kanału do łańcucha. Dust to określenie takich drobnych kwot. Dust exposure mierzy ich łączną wartość podlegającą temu ograniczeniu. 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. [2] [1]

Poniższa kontrola jest przeznaczona dla operatorów węzłów i programistów. Dekodowanie przedstawia zapis jako czytelne pola; niczego nie wysyła i samo nie dowodzi spełnienia wszystkich warunków. 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. [1] [2]