OP_CHECKTEMPLATEVERIFY

Анна хочет отложить средства, чтобы позднее разделить их между Петром и Евой. Она не хочет полагаться только на обещание того, кто будет хранить деньги. В Bitcoin непотраченные средства записаны как выходы транзакций, UTXO: каждый содержит сумму и условия её использования. CTV мог бы добавить к этим условиям конкретный план распределения. При расходовании выхода узлы — программы, проверяющие правила сети, — сверяли бы новую транзакцию с планом. Другой получатель или отклонение от заданной суммы не прошли бы проверку. Автор предложения Jeremy Rubin описал его в BIP119; номер BIP был присвоен в 2020 году. [1] [3]

Шаблон задаёт устройство перевода: на сколько предыдущих выходов ссылаются входы и какие новые выходы должны появиться. Для новых выходов он фиксирует суммы и скрипты, то есть условия будущего расходования. Если подробнее, BIP119 также охватывает версию транзакции; nLockTime — поле временных ограничений всей транзакции; поля входов nSequence, которые могут влиять на временные блокировки; и индекс проверяемого входа. Если какой-либо scriptSig, входной скрипт с данными для расходования, непустой, добавляется также хеш всех полей scriptSig. Это не просто список получателей: изменение другого охваченного поля тоже создаст иной шаблон. Ссылки на конкретные прежние монеты и их суммы — отдельный вопрос, разобранный ниже. [1]

Байт — обычная единица объёма данных. Предлагаемая проверка использует 32-байтовый хеш шаблона, вычисленный с помощью SHA256. Узел получает такой же отпечаток транзакции, расходующей выход, и отклоняет несовпадение. Цифровая подпись подтверждает разрешение на платёж с помощью закрытого ключа — секретного числового значения, не раскрывая сам ключ. Другая часть скрипта может требовать подпись; CTV не заменяет её повсеместно. Аргументы иной длины не выполняют эту проверку и зарезервированы для будущих расширений, хотя политика ретрансляции может их отклонять. Неверный аргумент поэтому не означает автоматически надёжную блокировку. [1] [4] [12]

В следующем примере суммы указаны в sats, наименьших единицах биткоина. Хеш шаблона не содержит непосредственно outpoint — ссылок на конкретные расходуемые UTXO — или их входных сумм. Но число входов зафиксировано. Допустим, разрешён ровно один вход, а выходы в сумме составляют 99 000 sats. Вход на 100 000 sats оставляет 1 000 sats комиссии. Вход меньше суммы выходов не оплатит такую транзакцию. Больший вход при неизменных выходах увеличит комиссию, а не создаст автоматически сдачу. [6] [9]

Шаблон может предписывать переход к другому выходу, скрипт которого содержит задержку и путь восстановления. Так можно построить хранилище со временем на реакцию на нежелательное снятие. Но CTV — не вся система защиты: важны ключи, условия следующих выходов, наблюдение и своевременное подтверждение восстановления. Часть ограничений можно создать заранее подписанными транзакциями, однако с другими требованиями к сотрудничеству и удалению ключей. [8] [5]

Блок объединяет транзакции в пакет, добавляемый в общую историю. При предлагаемом управлении перегрузкой сначала подтверждается выход, связывающий средства с последующим распределением. Отдельные выходы получателей могут появиться в следующих транзакциях, например при меньшей загрузке сети. Получателям нужны сведения о плане и возможность реализовать своё право. Это отличается от обычного платежа, уже подтверждённого на их адрес, и не превращает ограниченный блок в бесконечное пространство. [7] [11]

Кошелёк — приложение или устройство для получения и отправки биткоинов. Анна может подготовить план задолго до публикации платежа, ещё не зная будущих комиссий. Фиксированные выходы не позволяют ей произвольно уменьшить сумму, возвращаемую в кошелёк, и предложить разницу майнеру. Поэтому конструкция должна предусматривать способ добавить комиссию. Один вариант — подходящий CPFP: следующая транзакция расходует выход исходной и предлагает комиссию, способную заинтересовать майнера во включении обеих. Другой вариант — шаблон, изначально рассчитанный на дополнительный вход. Его нельзя просто добавить к шаблону, допускающему только один вход. Mempool — набор неподтверждённых транзакций отдельного узла; принятие в него ещё не гарантирует попадания в блок. [2] [6] [10]

Сам CTV проверяет конкретный шаблон; это не универсальный язык для чтения и произвольного сравнения всех данных транзакции. Он позволяет готовить разветвлённые планы будущих транзакций, но не равнозначен общим рекурсивным Covenants. Сочетания с другими предлагаемыми инструкциями могут дать больше возможностей. Поэтому нужно понимать, использует ли пример только CTV или целый пакет изменений. [1] [2]

При проверке 17 октября 2026 года BIP119 имеет статус Draft, то есть остаётся предложением в разработке. Он наделил бы новой проверочной функцией OP_NOP4 — команду, которая сегодня не оказывает действия при проверке блока. Такое ужесточение общих правил называется Soft Fork. Сам документ, однако, не определяет активацию. Публикация BIP не превращает opcode в реально применяемую команду; код, поддержка разработчика или демонстрационный кошелёк тоже не доказывают её применения в основной сети Bitcoin, mainnet. Для каждой демонстрации поэтому нужно знать сеть, правила и другие предложения, от которых она зависит. [1]

Пока правило не применяется, одного его присутствия в скрипте недостаточно для защиты: консенсус и отказ mempool — разные вещи. Даже при поддержке CTV единственный обязательный шаблон без запасного пути может навсегда запереть недостаточно профинансированный выход. Новый небольшой депозит при этом не блокирует автоматически другие правильно профинансированные UTXO. Безопасный проект требует проверки сумм, комиссий, резервных копий и всех путей восстановления. [1] [4] [6]