Timelock

Anna i Pavel mogą ustalić, że wspólne środki wydają razem w dowolnym momencie, ale Anna sama może to zrobić dopiero po określonym czasie. Jeśli Pavel przestanie odpowiadać, opóźniona gałąź zapewni uzgodnioną wcześniej drogę odzyskania środków. Gałąź oznacza tu jeden z dozwolonych sposobów wydania; każdy może mieć inne warunki. Blokada nie musi więc zamykać wszystkich możliwości naraz. Reguły muszą należeć do wyjścia od chwili jego utworzenia. Nie wystarczy później dopisać w zwykłym portfelu „odblokuj za tydzień”. Nawet po czekaniu Anna potrzebuje odpowiedniego klucza i danych do zbudowania poprawnej transakcji. Timelock pomaga zarządzać dostępem, ale nie odzyskuje zgubionych kluczy. [3]

Blokada bezwzględna wyznacza stałą granicę zapisaną w polu nLockTime transakcji. Jeśli skuteczny nLockTime transakcji wynosi 1 000 000, pierwszym blokiem spełniającym ten warunek może być 1 000 001: równość jeszcze nie wystarcza. Blokada względna odmierza natomiast czas od potwierdzenia wydawanego wyjścia. Gdy wyjście Anny powstanie w bloku 1 000 000, a odpowiednia gałąź wymaga opóźnienia o 6 bloków, jego wydanie może spełnić ten warunek najwcześniej w bloku 1 000 006. To przykładowe liczby, nie obecna wysokość sieci. Wymagania dotyczące podpisów, innych wejść i dodatkowych blokad nadal obowiązują. Sześć bloków nie oznacza też dokładnie godziny: bloki pojawiają się w nieregularnych odstępach. Względne czekanie nie zaczyna się przy tworzeniu portfela ani wtedy, gdy Anna postanowi użyć pieniędzy. [1] [2] [5]

Załóżmy, że wymagany okres Anny właśnie minął. Sieć nie zacznie działać za nią. Ktoś nadal musi zbudować transakcję lub użyć przygotowanej, dostarczyć podpisy, zapłacić opłatę i przekazać ją sieci. Dopiero wtedy górnik może umieścić ją w bloku. Spełniony Timelock to jeden spełniony warunek, a nie rezerwacja miejsca czy automatyczny przelew. Zwykle określa początek możliwości wydania, nie chwilę jej samoczynnego wygaśnięcia. Przy reorganizacji część łańcucha zostaje zastąpiona inną poprawną gałęzią. Może to zmienić potwierdzenie wyjścia i obliczenie względnego opóźnienia. Przy własnej konstrukcji trzeba wcześniej sprawdzić wszystkie gałęzie, obsługę w portfelu oraz kopie kluczy i reguł wydawania; czas nie naprawi źle określonego warunku. [2] [5]

Warunki czasowe używają Median Time Past, w skrócie MTP. Dla sprawdzanego bloku jest to mediana znaczników czasu ostatnich 11 bloków, kończąc na poprzednim. Posortuj ich czasy i wybierz środkowy, czyli szósty: to mediana, nie średnia arytmetyczna. Regułę opisuje BIP113, a Bitcoin Core oblicza ją przez GetMedianTimePast. Nie chodzi więc o bieżącą godzinę telefonu Anny ani znacznik czasu proponowanego bloku. Północ w kalendarzu nie musi być momentem spełnienia blokady. Blokady wysokości czekają natomiast na bloki, a nie odliczają sekund. [4]

Możemy już rozróżnić cztery nazwy z dokumentacji. nLockTime jest polem całej transakcji określającym bezwzględną granicę. nSequence przy wejściu zawiera względne opóźnienie według BIP68. Sam nLockTime nie blokuje jednak UTXO, czyli niewydanego wyjścia, przed inną transakcją z innymi ustawieniami. Osoba uprawniona do wydania może stworzyć taką transakcję, jeśli reguły wyjścia tego nie zabraniają. Bitcoin Script to język służący do zapisywania tych reguł wydawania środków. OP_CHECKLOCKTIMEVERIFY, czyli CLTV według BIP65, wymaga odpowiedniego ustawienia bezwzględnego w używanej gałęzi. OP_CHECKSEQUENCEVERIFY, czyli CSV według BIP112, sprawdza ustawienie względne, a rzeczywiste opóźnienie wymusza BIP68. Ani CLTV, ani CSV nie wysyłają pieniędzy i nie dodają brakującego podpisu. Inna dozwolona gałąź może działać na innych warunkach. [1] [2] [3]

Dalsze sekcje są materiałem technicznym. Pole to informacja zapisana w transakcji; wejście wskazuje wyjście, które ma zostać wydane. Każde wejście ma pole nSequence. Szczególna wartość może wyłączyć działanie nLockTime, więc samo wpisanie daty nie wystarczy. nLockTime jest nieujemnym polem 32-bitowym; zero wyłącza bezwzględny warunek czasowy. Jeśli wszystkie wejścia są ustawione na SEQUENCE_FINAL o wartości 0xffffffff, niespełniony nLockTime jest ignorowany. Skuteczna blokada bezwzględna wymaga, aby co najmniej jedno wejście miało inną wartość nSequence. Oceniana jest ta konkretna transakcja, a nie trwałe zamrożenie jej wejść. [5] [7]

Jedno pole może oznaczać dwie rzeczy, które rozdziela próg liczbowy. Znacznik czasu Unix wyraża czas w sekundach od początku 1970 roku w UTC. Blok kandydujący to blok, w którym miałaby znaleźć się sprawdzana transakcja. LOCKTIME_THRESHOLD ma wartość 500000000. Niższy nLockTime oznacza wysokość bloku, a wartość równa lub wyższa znacznik czasu Unix. Przy włączonej kontroli bezwzględnej nLockTime musi być ściśle mniejsze od wysokości bloku kandydującego lub właściwego MTP. Równość nie wystarcza; nie chodzi o kwotę, średnią wysokość ani datę aktywacji protokołu. [5] [8]

Operand to wartość przekazana instrukcji, a opcode to sama instrukcja Script. CLTV porównuje wymaganie zapisane w gałęzi z ustawieniem transakcji. Osobna kontrola sprawdza, czy łańcuch posunął się dostatecznie daleko. To więcej niż porównanie dzisiejszej daty z jedną liczbą. OP_CHECKLOCKTIMEVERIFY wymaga nieujemnego operandu, takiego samego typu wysokość/czas jak nLockTime oraz operandu mniejszego lub równego nLockTime. Odpowiednie wejście wydające nie może mieć nSequence 0xffffffff. Opcode nie odczytuje bezpośrednio zegara ani wysokości łańcucha; ustawienia transakcji sprawdza się oddzielnie podczas kontroli jej poprawności czasowej. Pozostałe warunki Script nadal muszą być spełnione. [1] [6]

Liczba nSequence zawiera zarówno okres oczekiwania, jak i przełączniki określające jej znaczenie. Bit to zero lub jedynka w tym zapisie; jego ustawienie może włączać opcję. Podane dalej pozycje bitów są częścią formatu, nie liczbą potwierdzeń. Dla transakcji w wersji 2 lub wyższej BIP68 włącza warunek względny dla wejść bez ustawionego bitu 31. Najmłodsze 16 bitów określa opóźnienie; bit 22 wybiera jednostki po 512 sekund, a w przeciwnym razie używane są bloki. Opóźnienie blokowe liczy się od wysokości potwierdzenia wydawanego wyjścia. Opóźnienie czasowe liczy się od MTP bloku przed jego potwierdzeniem do MTP przed blokiem kandydującym. Nie chodzi o czas od utworzenia transakcji w portfelu. [2] [5]

CSV podobnie sprawdza względne oczekiwanie. Maska wybiera odpowiednie bity nSequence, a disable flag jest przełącznikiem wyłączenia. Lightning Network to sieć kanałów płatniczych: uczestnicy aktualizują w nich uzgodniony podział wspólnie zablokowanych środków. Opóźnienie daje drugiej stronie czas na reakcję, gdy ktoś opublikuje stary, unieważniony stan. Commitment transaction zapisuje podział środków; klucz unieważniający pozwala drugiej stronie wydać odpowiednie wyjście unieważnionej wersji przez gałąź karną. OP_CHECKSEQUENCEVERIFY z aktywnym nieujemnym operandem wymaga wersji co najmniej 2, wyłączonej flagi disable wejścia, zgodnego typu opóźnienia i wystarczającej wartości nSequence po zastosowaniu maski. Rzeczywisty wiek oddzielnie wymusza BIP68. CSV pozwala utworzyć opóźnioną gałąź odzyskiwania. Dla wyjścia Lightning to_local opóźnienie to_self_delay ogranicza właściciela transakcji commitment; druga strona z prawidłowym kluczem unieważniającym może użyć gałęzi karnej bez tego opóźnienia. [3] [9]

Dwie niemal identyczne liczby mogą działać inaczej. Poniższe wartości zaczynające się od 0x zapisano szesnastkowo. NOP to instrukcja, która nie dodaje tu ograniczenia czasowego. Ważne jest też, czy przełącznik znajduje się w wejściu transakcji, czy w wartości przekazanej CSV. Bit 31 to SEQUENCE_LOCKTIME_DISABLE_FLAG, który wyłącza względną interpretację BIP68 tylko dla danego wejścia. Wartość 0xfffffffe zawiera ten bit, ale nie jest SEQUENCE_FINAL: pozwala na skuteczne nLockTime i CLTV. Wartość 0xffffffff jest finalna. Nieujemny operand CSV z ustawioną flagą disable zachowuje się jak NOP; ustawiona flaga w wejściu nie spełnia jednak aktywnego wymagania CSV. Tych dwóch przypadków nie wolno mylić. [3] [7]

RPC to polecenie do pracy z własnym węzłem, czyli programem sprawdzającym bloki i transakcje Bitcoina. Dekodowanie tylko zamienia zapisane dane w czytelny wykaz; polecenie testowe sprawdza następnie, czy konkretna podpisana transakcja przeszłaby kontrolę. Mempool to lokalna lista oczekujących transakcji węzła. RPC decoderawtransaction w Core 31 pokazuje version, locktime i sequence poszczególnych wejść. Dla CLTV/CSV sprawdź faktycznie używany Script i wydawane wyjście; samo dekodowanie nie jest dowodem poprawności. RPC testmempoolaccept testuje podpisanego kandydata względem bieżącego łańcucha, reguł poprawności Bitcoina oraz lokalnych zasad przyjmowania transakcji przez węzeł, bez przyjęcia do mempoola i bez rozgłaszania. Sprawdź allowed i powód odrzucenia; powodzenie nie jest obietnicą przyszłego potwierdzenia. [10] [11] [12]