OP_CHECKSEQUENCEVERIFY

Опкод читает число из стека и сравнивает его с полем последовательности расходуемого входа, поэтому отсчет начинается, когда монета попадает в блок, а не в календарную дату. Его определил BIP-112, и сеть начала применять его на блоке 419 328 4 июля 2016 года. Каждый канал Lightning, который вы открываете, зависит от него.

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

Опкод 178 раньше был OP_NOP3 и ничего не делал, и именно так правило попало в сеть в виде мягкого форка (soft fork), а не раскола.

Проверка выполняется по трем входным значениям: числу в стеке, полю последовательности расходуемого входа и версии транзакции. Требуется версия 2 или выше, потому что правила относительной блокировки по времени из BIP-68 применяются только начиная с этой версии. Если старший бит любого из двух значений установлен, блокировка по времени отключается и опкод отказывается от проверки. В противном случае оба значения должны совпадать по единице измерения, а значение в стеке не должно превышать поле последовательности.

Единицы измерения бывают двух видов, и их нельзя смешивать в одном сравнении. Снимите определенный флаг, и число будет считать блоки; установите его, и число будет считать интервалы по 512 секунд. В обоих случаях доступно шестнадцать бит, поэтому потолок составляет 65 535 блоков, примерно 455 дней, или такое же количество интервалов по 512 секунд, что дает чуть меньше 389 дней. Все более длительное требует абсолютной блокировки по времени.

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

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

Lightning является крупнейшим пользователем по объему, и опкод входит в скрипт, защищающий вашу собственную сторону каждого канала.

Когда канал закрывается в одностороннем порядке, баланс закрывающей стороны попадает в выход, который нельзя забрать, пока не пройдет задержка, параметр to_self_delay из BOLT 3, обычно несколько сотен блоков. Задержка существует для того, чтобы у другого участника было окно опубликовать аннулирование и забрать средства, если при закрытии использовалось устаревшее состояние. Ваши деньги в любом случае в безопасности, но именно поэтому принудительное закрытие оставляет вас в ожидании день или дольше, тогда как кооперативное закрытие выплачивает средства немедленно.

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

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

OP_CHECKSEQUENCEVERIFY vs OP_CHECKLOCKTIMEVERIFY

CSV спрашивает, как долго существует монета; CLTV спрашивает, который час. Два опкода стоят рядом в нумерации, 178 и 177, и выбираются для совершенно разных задач.

Используйте абсолютную форму, когда крайний срок является реальной датой: доверительное управление, которое открывается в 2030 году, возврат средств, который истекает на известной высоте. Используйте относительную форму, когда ожидание должно начинаться всякий раз, когда начинается контракт, что нужно любому скрипту, написанному один раз и используемому многократно. Lightning не мог использовать абсолютные блокировки по времени для задержек каналов, потому что канал, открытый сегодня, и канал, открытый в следующем году, требовали бы разных скриптов. Кроме того, они появились с разницей в несколько месяцев: CLTV на блоке 388 381 14 декабря 2015 года, а CSV в июле следующего года, и второй появился во многом потому, что первого было недостаточно для построения платежных каналов.