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.