Timelock obejmuje nLockTime, OP_CHECKLOCKTIMEVERIFY (CLTV/BIP65), względny nSequence według BIP68 oraz OP_CHECKSEQUENCEVERIFY (CSV/BIP112). Pola transakcji określają czasowe warunki poprawności; Script może wymuszać ich ustawienia. Warianty czasowe używają Median Time Past (MTP), a nie zegara portfela. Spełnienie blokady nie gwarantuje przyjęcia ani potwierdzenia.
nLockTime i CLTV tworzą parę bezwzględną, a BIP68 i CSV względną. nLockTime ogranicza konkretną transakcję w całości; samo nie blokuje UTXO przed inną transakcją o innych ustawieniach. CLTV lub CSV w wykonywanej gałęzi Script wymuszają odpowiednie pola transakcji wydającej. Inna dozwolona gałąź może mieć inne warunki. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 68 — Relative lock-time] [BIP 112 — CHECKSEQUENCEVERIFY]
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 inne nSequence. Oceniana jest ta konkretna transakcja, a nie trwałe zamrożenie jej wejść. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Sequence constants]
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. [Bitcoin Core v31.0 — Transaction finality] [Bitcoin Core v31.0 — Locktime threshold]
BIP113 używa do czasowej finalności MTP poprzedniego bloku: mediany znaczników czasu ostatnich 11 bloków kończących się tym blokiem. Nie jest to średnia arytmetyczna, bieżący czas użytkownika ani znacznik czasu bloku kandydującego. Bitcoin Core używa GetMedianTimePast; samo osiągnięcie daty kalendarzowej nie gwarantuje spełnienia blokady. [BIP 113 — Median time-past]
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. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v31.0 — Script interpreter]
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. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]
OP_CHECKSEQUENCEVERIFY z aktywnym nieujemnym operandem wymaga wersji co najmniej 2, wyłączonej flagi disable wejścia, zgodnego typu opóźnienia i wystarczającego zamaskowanego nSequence. 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. [BIP 112 — CHECKSEQUENCEVERIFY] [BOLT 3 — Commitment transaction outputs]
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ć. [BIP 112 — CHECKSEQUENCEVERIFY] [Bitcoin Core v31.0 — Sequence constants]
Blokada czasowa określa warunek dopuszczalności, a nie harmonogram wysyłania. Portfel musi przechować lub utworzyć transakcję, dostarczyć podpisy i pozostałe dane, spełnić wszystkie warunki oraz zapewnić opłatę i rozgłoszenie. Lokalna polityka i wybór górnika nadal wpływają na potwierdzenie. Reorganizacja może zmienić wysokość potwierdzenia wejścia i jego względny wiek; upływ czasu nie gwarantuje nieodwracalnego wyniku. [BIP 68 — Relative lock-time] [Bitcoin Core v31.0 — Transaction finality]
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 oraz lokalnej oceny konsensusu i polityki, bez przyjęcia do mempoola i bez rozgłaszania. Sprawdź allowed i powód odrzucenia; powodzenie nie jest obietnicą przyszłego potwierdzenia. [Bitcoin Core 31.0 — decoderawtransaction RPC] [Bitcoin Core 31.0 — testmempoolaccept RPC] [Bitcoin Core v31.0 — Mempool RPC implementation]
Pełniejszy obraz uzyskasz, czytając to hasło razem z CHECKLOCKTIMEVERIFY, CHECKSEQUENCEVERIFY, Lightning Network, Payment Channel, Transakcja, Bitcoin Script. Do tego hasła prowadzą również odsyłacze z Potwierdzenie, Bitcoin Script, HTLC, CHECKLOCKTIMEVERIFY.