CLTV

Anna projektuje przechowywanie środków, w którym zwykłe płatności zatwierdza wspólnie z Piotrem. Na wypadek dłuższej nieobecności chce również ścieżki awaryjnej dostępnej dopiero po wybranej granicy. CLTV zapisuje ten warunek czasowy w skrypcie, czyli zasadach wydawania wcześniej otrzymanych monet. Samo pole nLockTime opóźniłoby tylko konkretną transakcję. CLTV uniemożliwia obejście tej ścieżki nową transakcją z niższą granicą. Inne gałęzie mogą jednak mieć inne zasady. [1] [5]

CLTV nie rozpoznaje właściciela ani nie wysyła pieniędzy. Jeśli ścieżka awaryjna wymaga podpisu Anny, nadal musi go ona dostarczyć po spełnieniu warunku czasowego. Klucz prywatny to tajna wartość liczbowa służąca do utworzenia takiego podpisu. Upływ czasu nie odtwarza zgubionego klucza prywatnego. Monety nie trafiają też automatycznie na inny adres: ktoś musi przygotować, podpisać i rozgłosić poprawną transakcję. Jeżeli inna gałąź pozwala wydać je wcześniej, blokada w ścieżce awaryjnej sama nie ogranicza tej możliwości. [1]

Blok grupuje transakcje w pakiet dołączany do wspólnej historii. CLTV pasuje do warunku związanego z ustalonym punktem, a nie do wymagania, by odczekać określoną liczbę bloków od otrzymania tych monet. To drugie zapewnia CSV wraz z BIP 68, zasadami blokad względnych. Liczy się wtedy potwierdzenie konkretnego wyjścia, czyli otrzymanej kwoty z warunkami wydania. Żadne rozwiązanie nie gwarantuje dokładnej daty kalendarzowej. Tempo wydobycia jest zmienne, a reorganizacja może zmienić potwierdzoną historię. Podczas reorganizacji sieć przyjmuje inną poprawną gałąź łańcucha, zastępując część wcześniejszej historii bloków. [1] [7] [8] [9]

CLTV rozróżnia dwa typy wartości. Poniżej 500000000 wartość oznacza wysokość bloku, jego pozycję w łańcuchu. Od tej granicy oznacza znacznik czasu, czyli czas zapisany liczbowo. Warunek skryptu i nLockTime transakcji wydającej muszą używać tego samego typu. Nie wystarczy porównać wielkości liczb: pozycja bloku i czas nie mają tego samego znaczenia. [1] [3] [5]

Full Node, czyli węzeł samodzielnie weryfikujący zasady, porównuje nieujemną granicę ze skryptu z bezwzględnym nLockTime transakcji. Granica nie może przewyższać nLockTime; równość jest w tej kontroli dozwolona. Niezależnie od tego transakcja musi spełnić zasady włączenia do konkretnego bloku. CLTV nie odczytuje zegara komputera i nie zatrzymuje programu do rana. Nieudana kontrola oznacza, że ta próba skorzystania ze ścieżki wydania jest niepoprawna. [1] [3] [4]

Wejście transakcji wskazuje wcześniej otrzymane monety, które są wydawane. Jednym z jego pól jest nSequence. We wejściu sprawdzanym przez CLTV nie może ono mieć wartości 0xffffffff, specjalnego oznaczenia sekwencji finalnej. Gdyby wszystkie wejścia miały tę wartość, nLockTime można byłoby wyłączyć. CLTV zapobiega temu, wymagając niefinalnej sekwencji w tym wejściu. Nie ustala to jednak automatycznie konkretnego względnego czasu oczekiwania; odpowiadają za niego inne zasady. [1] [3] [4]

Załóżmy transakcję z nLockTime równym 900000 i niefinalnym wejściem. Z punktu widzenia tego warunku czasowego najwcześniejszy możliwy blok to 900001. Włączenie wymaga bowiem, by nLockTime było ściśle mniejsze od wysokości proponowanego bloku. Blok 900000 nie wystarczy, choć samo porównanie w CLTV dopuściło równość. „Finalność” oznacza tu możliwość włączenia, a nie nieodwracalność płatności. Opłata, inne warunki i wybór górnika mogą jeszcze opóźnić potwierdzenie. [4]

Dla znacznika czasu BIP 113 używa Median Time Past poprzedniego bloku: środkowej wartości uporządkowanych znaczników czasu ostatnich maksymalnie 11 bloków. To nie zegarek użytkownika ani czas bloku, który jest właśnie wydobywany. Czasowe nLockTime musi być ściśle mniejsze od tej wartości. Nie można więc obiecać wydania środków dokładnie w lokalne południe. Warunek ma znaczenie weryfikowalne przez sieć, ale nie jest precyzyjnym harmonogramem płatności. [2] [4]

Podczas wykonywania skrypt używa stosu, roboczego miejsca na układane dane. CLTV sprawdza swój argument czasowy, ale go nie usuwa. W prostym schemacie po OP_CHECKLOCKTIMEVERIFY następuje więc OP_DROP, które usuwa argument; potem dodawany jest klucz publiczny, a OP_CHECKSIG sprawdza podpis. Klucz publiczny służy do sprawdzania podpisów i nie musi być tajny. To wyjaśnienie ról instrukcji, nie gotowy przepis na zablokowanie pieniędzy. Muszą też zgadzać się wersja skryptu, dane początkowe i wszystkie inne ścieżki wydania. [1] [3]

BIP 65 wprowadził CLTV jako soft fork, zaostrzenie zasad zastępujące wcześniejsze OP_NOP2. Nie jest to zatem tylko pomysł na przyszłą funkcję. Nadal trzeba sprawdzić całą konstrukcję: typ granicy, nLockTime, nSequence, podpisy i alternatywne gałęzie. Szczegóły techniczne można zweryfikować w Bitcoin Core v29.0 i podanych specyfikacjach. Dla użytkownika najważniejsze jest zrozumienie, kto może wydać środki przed granicą i po niej oraz jakie są możliwości odzyskania dostępu. [1] [3] [6] [10]