nLockTime и nSequence: как Bitcoin задаёт временные ограничения

nLockTime задаёт высоту блока или Unix-время

Поле nLockTime применяется к транзакции целиком. Значение ниже порога LOCKTIME_THRESHOLD трактуется как высота блока, значение от порога – как время. Транзакция не является окончательной до достижения соответствующей точки, если поле и sequence позволяют учитывать locktime.

Если все входы используют финальный nSequence, абсолютная блокировка может быть отключена для обычной проверки финальности. Поэтому одного значения nLockTime недостаточно: нужно прочитать sequence каждого входа и правила обработки транзакции.

• nLockTime шкала определена
• финальные sequence проверены
• абсолютный порог сопоставлен с chain data

BIP68 использует nSequence конкретного входа

При версии транзакции не ниже 2 и активной проверке sequence locks поле nSequence может задавать, сколько блоков или времени должно пройти с момента подтверждения потраченного выхода. Старший disable bit отключает такую интерпретацию. Отдельный type bit выбирает блоки или временной интервал; число хранится в ограниченной маской части поля.

Для time-based relative locktime используется гранулярность 512 секунд и median-time-past, а не точный секундомер от кошелька или wall clock. Блоковый вариант отсчитывает возраст UTXO в высотах. Различайте порог валидности по консенсусу и момент ретрансляции конкретным mempool.

• версия и disable bit проверены
• sequence прочитаны для каждого входа
• MTP учтён для временного режима

Операции скрипта проверяют locktime, заданный spending transaction

OP_CHECKLOCKTIMEVERIFY, введённый BIP65, проверяет совместимость значения в стеке с nLockTime и требует, чтобы sequence текущего входа не был финальным. OP_CHECKSEQUENCEVERIFY по BIP112 проверяет относительное ограничение входа по правилам BIP68. Это условия выполнения script, а не поля, которые сами по себе переводят или блокируют монеты без транзакции.

Значение в скрипте должно соответствовать типу height/time у проверяемого locktime. Отрицательные значения, несовпадение временной шкалы, недостаточный порог или невалидное сочетание sequence приводят к отказу скриптовой проверки. Для сложного redeem script проверяйте фактический путь расходования.

Проверяйте предыдущие выходы и поля каждого входа

Сохраните raw transaction, версию, nLockTime, все nSequence, высоты подтверждения предыдущих outputs и script, который должен исполниться. Для относительной блокировки важен возраст конкретного UTXO; для абсолютной – chain height или MTP по выбранной шкале.

Если кошелёк показывает «ожидание», узнайте, проверяет ли он локальный шаблон, mempool policy или фактическую consensus/script валидность. Не меняйте sequence или locktime вслепую: они входят в подписываемые данные, и изменение обычно требует новых подписей.

• зафиксируйте все inputs, а не один выбранный пример;
• сверьте предыдущие output heights и script;
• любое изменение подписанных полей согласуйте заново со всеми подписантами.

Чек-лист: nlocktime и nsequence: как bitcoin задаёт временные ограничения

• version транзакции записана;
• height и time шкалы не смешаны;
• каждый nSequence прочитан отдельно;
• absolute и relative locks различены;
• CLTV/CSV условия сверены со script;
• MTP учтён для временных sequence locks;
• после изменения полей подписи проверены повторно.

Материал подготовлен редакцией сайта и проверен 4 ноября 2026 года. Условия бирж, кошельков и блокчейн-сетей могут меняться. Перед операцией сверяйте данные в интерфейсе выбранного сервиса.