CLTV — скорочення назви інструкції OP_CHECKLOCKTIMEVERIFY у Bitcoin Script. Вона прив’язує витрачання до фіксованої межі висоти блоку або часу. Після її досягнення все одно потрібно виконати інші умови, створити транзакцію та включити її до блоку. Нічого не надсилається саме собою.
Анна продумує зберігання, за якого звичайні платежі вони з Петром схвалюють разом. На випадок тривалої недоступності вона хоче додати запасний шлях, доступний лише після обраної межі. CLTV дозволяє записати цю часову умову в скрипті — правилах витрачання раніше отриманих монет. Саме поле nLockTime відклало б лише конкретну транзакцію. CLTV не дає обійти умову цього шляху новою транзакцією з нижчою межею. В інших гілках можуть діяти інші правила. [1] [5]
CLTV не розпізнає власника й не переказує гроші. Якщо запасний шлях вимагає підпису Анни, його потрібно надати й після виконання часової умови. Приватний ключ — секретне числове значення, за допомогою якого створюють такий підпис. Втрачений приватний ключ не відновиться з плином часу. Монети також не перейдуть автоматично на іншу адресу: хтось має підготувати, підписати й поширити дійсну транзакцію. Якщо інша гілка дозволяє витратити їх раніше, часове обмеження запасної гілки саме собою її не обмежує. [1]
Блок об’єднує транзакції в пакет, який додають до спільної історії. CLTV підходить для умови, прив’язаної до наперед заданого моменту, а не для вимоги почекати певну кількість блоків після отримання цих монет. Другий варіант забезпечує CSV разом із BIP 68, правилами відносного блокування. Тут важливе підтвердження конкретного виходу — раніше отриманої суми з умовами витрачання. Жоден підхід не гарантує точної календарної дати. Темп майнінгу змінюється, а реорганізація може змінити підтверджену історію. Під час реорганізації мережа приймає іншу дійсну гілку ланцюга, замінюючи частину попередньої історії блоків. [1] [7] [8] [9]
CLTV розрізняє два типи значень. Число нижче 500000000 означає висоту блоку, його позицію в ланцюжку. Починаючи з цієї межі, значення означає часову мітку — числове подання часу. Умова скрипту й nLockTime транзакції витрачання мають використовувати однаковий тип. Просто порівняти величину чисел недостатньо: позиція блоку й час мають різний зміст. [1] [3] [5]
Full Node — вузол, який самостійно перевіряє правила, — порівнює невід’ємну межу зі скрипту з абсолютним nLockTime транзакції. Межа не повинна перевищувати nLockTime; рівність для цієї перевірки дозволена. Окремо мають виконуватися правила включення транзакції до конкретного блоку. CLTV не читає годинник вашого комп’ютера й не зупиняє програму до ранку. Невдала перевірка робить цю спробу використати шлях витрачання недійсною. [1] [3] [4]
Вхід транзакції вказує, які раніше отримані монети витрачаються. Серед його полів є nSequence. У вході, який перевіряє CLTV, воно не може дорівнювати 0xffffffff — спеціальному значенню фінальної послідовності. Якби таке значення мали всі входи, nLockTime можна було б вимкнути. CLTV запобігає цьому, вимагаючи нефінального значення для цього входу. Однак це не задає автоматично конкретного відносного періоду очікування: його визначають інші правила. [1] [3] [4]
Візьмімо умовну транзакцію з nLockTime, що дорівнює 900000, і нефінальним входом. За цією часовою умовою найраніший можливий блок — 900001. Для включення nLockTime має бути строго меншим за висоту блока-кандидата. Тому блоку 900000 недостатньо, хоча власне порівняння CLTV дозволило рівність. «Фінальність» тут означає придатність до включення, а не незворотність платежу. Комісія, інші умови та вибір майнера можуть додатково затримати підтвердження. [4]
Для часової мітки BIP 113 використовує Median Time Past попереднього блоку: середнє за позицією значення впорядкованих часових міток останніх щонайбільше 11 блоків. Це не ваш годинник і не час блоку, який зараз майнять. Часовий nLockTime має бути строго меншим за це значення. Тому не можна обіцяти доступність монет рівно опівдні за місцевим часом. Умова має зміст, який може перевірити мережа, але не є точним розкладом платежів. [2] [4]
Під час виконання скрипт працює зі стеком — робочою стопкою даних. CLTV перевіряє свій часовий аргумент, але не прибирає його. Тому в простій схемі після OP_CHECKLOCKTIMEVERIFY йде OP_DROP, що прибирає аргумент; далі до стека додають публічний ключ, а OP_CHECKSIG перевіряє підпис. Відкритий ключ використовують для перевірки підписів; його не потрібно тримати в таємниці. Це пояснення ролей інструкцій, а не готовий рецепт блокування грошей. Версія скрипту, початкові дані й усі інші шляхи витрачання також мають бути правильними. [1] [3]
BIP 65 запровадив CLTV як soft fork — посилення правил, що замінило колишню OP_NOP2. Це вже чинна можливість, а не лише пропозиція на майбутнє. Проте перевіряти потрібно всю конструкцію: тип межі, nLockTime, nSequence, підписи й альтернативні гілки. Технічні подробиці можна звірити з Bitcoin Core v29.0 та наведеними специфікаціями. Для користувача головне — розуміти, хто може витрачати кошти до й після межі та як працюють варіанти відновлення. [1] [3] [6] [10]
Для повної картини прочитайте також CSV, Opcode, Timelock, Bitcoin Script, Bitcoin, Full Node. На цю статтю також посилаються Timelock, HTLC, Opcode, CSV.