Point Time Locked Contract łączy blokadę punktową z czasową ścieżką zwrotu: ukończenie adaptor signature ujawnia odpowiadający skalar, którego poprzedni uczestnik używa do ukończenia własnego podpisu, a po wygaśnięciu timelock środki można odzyskać; jest to element protokołu, a nie dzisiejszy standardowy typ płatności Lightning.
HTLC uzależnia ścieżkę powodzenia od znajomości preimage wspólnego hasha; PTLC zamiast tego używa punktu T = t·G oraz adaptor signature, którą można ukończyć wyłącznie znając skalar t. Ścieżka czasowa pozostaje: gdy rozliczenie nie nastąpi, nadawca odzyskuje środki po timeout. [1]
Odbiorca wybiera tajny skalar i publikuje odpowiadający punkt. Każda para sąsiednich węzłów przygotowuje niepełne podpisy związane z własną blokadą punktową; ukończenie ostatniego podpisu ujawnia różnicę między adapterem a ważnym podpisem i pozwala rozliczyć trasę wstecz. [1]
Nadawca może dodać różne losowe skalary dla poszczególnych hop-ów, a węzły kolejno odejmują ich punkty. Dwa współpracujące węzły routingu nie widzą wtedy tego samego payment hash jak w zwykłym HTLC; nadal możliwa jest korelacja według kwoty, czasu, wygaśnięcia lub topologii. [4]
BIP 340 nadaje podpisom Schnorra równanie liniowe, dzięki któremu adaptery podpisów łatwiej składać niż z ECDSA. Przy kluczu agregowanym udany spend on-chain może wyglądać jak zwykły podpis, lecz rzeczywista oszczędność miejsca zależy od konstrukcji kanału, protokołu multisignature i ścieżki awaryjnej. [2]
Bezpieczeństwo nie opiera się wyłącznie na punkcie i timelock. Implementacja musi sprawdzać adapter, wiązać podpis z wiadomością i kluczem, chronić nonce, bezpiecznie wydobywać skalar, zachować refund i obsłużyć przerwanie połączenia; błąd może ujawnić klucz albo spowodować utratę środków. [1]
Obecny bazowy BOLT #2 nadal opisuje update_add_htlc, update_fulfill_htlc i htlc_signature. PTLC nie jest więc interoperacyjną funkcją zwykłej Lightning Network tylko dlatego, że Taproot i BIP 340 są aktywne w Bitcoinie; potrzebuje uzgodnionych komunikatów, stanów kanału i zgodnych implementacji. [3]
Dyskusja deweloperów z 2025 wskazuje brak dojrzałych, standaryzowanych narzędzi dla adaptor signatures z MuSig2 oraz samodzielnych adapterów Schnorra w popularnych bibliotekach. PTLC jest rozwiniętą koncepcją techniczną, lecz publiczny stan narzędzi i specyfikacji nie pozwala twierdzić, że jest szeroko wdrożony. [5]
PTLC może poprawić dekorelację routowanych płatności, proof of payment, atomowe płatności wielotrasowe i niektóre swaps. Sam nie rozwiązuje dostępności kanału, zarządzania płynnością, utraty stanu, złośliwego timingu ani pełnej anonimowości; jego korzyści trzeba oceniać wraz z onion routing i konstrukcją kanału. [4]
Pełniejszy obraz uzyskasz, czytając to hasło razem z HTLC, Schnorr Signature, Lightning Network, Taproot, Payment Channel, Lightning Routing. Do tego hasła prowadzą również odsyłacze z Trampoline Routing.
01Czy zwykła Lightning Network używa dziś PTLC zamiast HTLC?+
Nie jako wspólnej interoperacyjnej podstawy. Aktualne specyfikacje BOLT nadal definiują komunikaty i podpisy HTLC. PTLC wymaga dodatkowych narzędzi kryptograficznych, komunikatów, przejść stanów i zgodności implementacji; sama aktywacja Taproot nie wykonała tej migracji.
02Dlaczego PTLC zapewnia więcej prywatności niż HTLC?+
Wiele hop-ów HTLC może przenosić ten sam payment hash, dając współpracującym węzłom bezpośrednią wartość korelacyjną. PTLC pozwala każdemu hop-owi zmienić blokadę przez dodanie lokalnego punktu. Kwota, timing, wygaśnięcie i pozycja w sieci nadal mogą łączyć płatność.