OP_CHECKTEMPLATEVERIFY

Этот опкод описан в BIP-119, Jeremy Rubin опубликовал первый черновик в январе 2020 года, и сеть его не приняла. Опкод брал бы из стека хеш длиной 32 байта и завершался бы ошибкой, если хеш шаблона расходующей транзакции, то есть ее версии, locktime, числа входов, значений sequence, выходов и индекса входа, не совпадает. Ничто в вашем кошельке его не использует, и не будет использовать, пока не активируется мягкий форк.

Как это работает

Статус: предложен, не активирован. BIP-119 остается черновиком с 2020 года, предложенная в 2022 году активация вызвала достаточно возражений, чтобы ее отложили, а в Bitcoin Core нет параметров развертывания для него.

В основе проекта лежит старый прием обновления. Опкод 179, ранее OP_NOP4, сейчас не делает вообще ничего, поэтому скрипт, содержащий его, считается допустимым для каждого узла сети. Мягкий форк переопределил бы этот байт так, чтобы обновленные узлы выполняли проверку, а старые продолжали пропускать скрипт, тем же путем, которым прошли CLTV через OP_NOP2 и CSV через OP_NOP3.

То, что попадает в хеш, выбрано с необычной тщательностью. Шаблон охватывает выходы, суммы, число входов и их значения sequence, но намеренно оставляет за рамками outpoints, то есть txid монет, которые расходуются. Их исключение имеет два следствия, на которых держится весь проект. Во-первых, хеш можно вычислить до того, как появится финансирующая транзакция, и именно это позволяет построить цепочку будущих расходов, а затем профинансировать ее. Во-вторых, шаблон не может содержать обязательство в отношении самого себя, поэтому ограничение нельзя сделать повторяющимся бесконечно, и потому сторонники называют его узким ковенантом.

В результате получается расход, txid которого известен заранее. Кошелек может выдать вам квитанцию о платеже, который появится позже, и доказать, что никакой другой расход этой монеты невозможен.

Где это встречается

OP_CHECKTEMPLATEVERIFY нигде не выполняется в mainnet, поэтому смотреть стоит на набор приложений, построенных на пользовательских signet, которые были бы выпущены, если бы опкод активировался.

Чаще всего упоминают управление перегрузкой. Биржа, столкнувшаяся со скачком комиссий, выплачивает 1000 выводов одним выходом, который фиксирует дерево последующих платежей; каждый пользователь затем может раскрыть свою ветвь и получить средства, когда комиссии упадут, а биржа потратила один выход вместо тысячи. Второе место занимают хранилища: вывод должен сначала поступить на промежуточный выход с задержкой, что дает вам окно, чтобы вернуть средства в холодное хранение, если запрос был не вашим. Платежные пулы и неинтерактивное финансирование каналов Lightning используют ту же схему: сначала фиксация, затем раскрытие.

Для любого, кто покупает биткоин, честная позиция состоит в том, что это не меняет ничего, чем вы можете воспользоваться. Аббревиатуру стоит узнавать потому, что она постоянно возникает в спорах о том, чем биткоин должен стать, и потому, что функции хранилища, которые рекламируют некоторые кастодиальные сервисы, были бы действительно обеспечены принудительно, если бы опкод когда-нибудь активировался.

OP_CHECKTEMPLATEVERIFY vs OP_CHECKLOCKTIMEVERIFY

OP_CHECKTEMPLATEVERIFY ограничивает форму расходующей транзакции, тогда как OP_CHECKLOCKTIMEVERIFY ограничивает, когда может произойти расход, и ничего не говорит о том, куда уходят деньги. Почти одинаковые названия постоянно приводят к путанице между ними.

Другое различие состоит в статусе, и именно оно важно. OP_CHECKLOCKTIMEVERIFY действует с блока 388 381 от 14 декабря 2015 года, и его ежедневно используют Lightning, скрипты эскроу и кошельки для наследования. OP_CHECKTEMPLATEVERIFY не обеспечивался принудительно ни одним узлом в mainnet. Если сервис говорит вам, что ваши биткоины защищены обязательством шаблона, он описывает то, что сеть сейчас не проверяет.