129 / 691CLTV

CHECKLOCKTIMEVERIFY

CLTV wymusza bezwzględny warunek czasowy w ścieżce wydania. Nie jest budzikiem: po osiągnięciu granicy nadal potrzebna jest poprawna i potwierdzona transakcja.

OP_CHECKLOCKTIMEVERIFY porównuje nieujemny argument stosu z bezwzględnym nLockTime transakcji wydającej i sprawdza nSequence wejścia. Reguły finalności transakcji następnie sprawdzają rzeczywistą dopuszczalność czasową.

Samo nLockTime opóźnia konkretną transakcję. CLTV w warunku wyjścia zapobiega obejściu tej samej ścieżki inną transakcją z niższym nLockTime; pozostałe ścieżki ocenia się oddzielnie. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]

Wartość poniżej 500000000 oznacza wysokość bloku, od tej granicy znacznik czasu. Argument CLTV i nLockTime muszą mieć ten sam typ; porównanie liczb nie wystarczy. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

Argument musi być nieujemny i nie większy od nLockTime. CLTV nie czyta zegara komputera ani nie wstrzymuje skryptu; niespełniona kontrola oznacza błąd walidacji. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

nSequence badanego wejścia nie może wynosić 0xffffffff. Zapobiega to wyłączeniu nLockTime przez finalne sequence; CLTV nie wymaga określonego niezerowego opóźnienia względnego. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

Dla nLockTime = 900000 i niefinalnego wejścia najwcześniejsza wysokość kandydata to 900001: finalność wymaga nLockTime mniejszego od wysokości bloku. Równość argumentu CLTV nie przesuwa tej granicy. [Bitcoin Core v29.0 — Transaction finality]

Według BIP 113 czasowe nLockTime porównuje się z Median Time Past poprzedniego bloku, medianą czasów ostatnich maksymalnie 11 bloków. Wartość musi być ściśle mniejsza; nie jest to dokładna lokalna godzina dostarczenia. [BIP 113 — Median time-past lock-time calculations] [Bitcoin Core v29.0 — Transaction finality]

CLTV nie zużywa argumentu. W <wysokość> OP_CHECKLOCKTIMEVERIFY OP_DROP <klucz> OP_CHECKSIG usuwa go OP_DROP; to schemat warunku, nie gotowy przepis finansowania. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core v29.0 — Script interpreter]

Blokada czasowa sama nie upoważnia właściciela. Warunek podpisu nadal musi obowiązywać; inna gałąź może umożliwić wcześniejsze wydanie, a upływ czasu nie wysyła automatycznie płatności. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Developer Reference — Transactions]

CLTV ustala stały punkt, nie liczbę bloków od potwierdzenia wyjścia. CSV z BIP 68 dotyczy wieku wejścia; opóźnienia wydobycia i reorganizacje nie gwarantują stałej daty. [Bitcoin Core v29.0 — Transaction finality] [Bitcoin Developer Reference — Transactions]

BIP 65 wprowadził CLTV jako soft fork zastępujący OP_NOP2. Sprawdź całą ścieżkę, typ granicy, nLockTime, nSequence i opłatę; aktywna instrukcja nie gwarantuje szybkiego potwierdzenia. [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [Bitcoin Core 0.11.2 — BIP 65 release notes]

Pełniejszy obraz uzyskasz, czytając to hasło razem z CHECKSEQUENCEVERIFY, Bitcoin Script opcode, Timelock, Bitcoin Script. Do tego hasła prowadzą również odsyłacze z Timelock, HTLC, Bitcoin Script opcode, CHECKSEQUENCEVERIFY.

DOC · 001BIP 65 — OP_CHECKLOCKTIMEVERIFYSpecyfikacja ↗DOC · 002BIP 113 — Median time-past lock-time calculationsSpecyfikacja ↗DOC · 003Bitcoin Core v29.0 — Script interpreterDokumentacja ↗DOC · 004Bitcoin Core v29.0 — Transaction finalityDokumentacja ↗DOC · 005Bitcoin Developer Reference — TransactionsDokumentacja ↗DOC · 006Bitcoin Core 0.11.2 — BIP 65 release notesDokumentacja ↗
Najpierw źródła · To nie jest porada inwestycyjna