Timelock в Bitcoin: абсолютные и относительные ограничения
Иногда библиотеке нужно предусмотреть расходование только после определённого момента или после возраста выхода. Bitcoin поддерживает несколько связанных механизмов времени, которые легко перепутать. В уроке отделим абсолютную финальность транзакции от относительных условий и от коммерческого срока счёта.
Примеры ниже моделируют высоты блоков. Мы не создаём скрипты с реальными средствами и не проверяем их запуском. Ограничения времени полезны только при точном понимании всех путей расходования; ошибка может лишить владельца ожидаемого доступа.
Абсолютная граница
Поле nLockTime может задавать ограничение по высоте блока либо по времени в установленной интерпретации. Значение не означает резервирование будущего включения: после достижения условия транзакция лишь становится допустимой по соответствующему признаку, если остальные правила также выполнены.
Допустим, учебный план разрешает транзакцию не раньше определённой высоты. Пока выбранная цепочка ниже нужного условия, кошелёк и узел не должны считать её обычным финальным кандидатом. Когда граница достигнута, сохраняются необходимость подписи, доступность входа и подходящая политика распространения.
Влияние sequence на абсолютную финальность важно: максимальные значения могут отключать практический эффект nLockTime. Поэтому недостаточно изменить одно поле заголовка транзакции и предполагать, что ограничение работает. Совместимый кошелёк должен формировать весь согласованный набор полей.
Условие скрипта
OP_CHECKLOCKTIMEVERIFY позволяет связать расходование конкретного выхода с абсолютным ограничением через правила скрипта. Это отличается от добровольного выбора nLockTime в одной подготовленной транзакции. Если предыдущий выход содержит обязательное условие, подписант не может просто выбрать другую транзакцию без него и получить то же разрешение.
Для библиотеки это различие можно описать на архивном резерве. Сотрудник заранее создаёт одну транзакцию с будущей финальностью — это свойство подготовленного кандидата. А отдельный выход, который по своей политике требует временную границу, защищён самим условием расходования. В первом случае владелец ключа может иметь другой доступный путь, если исходный выход его допускает.
Время в скриптовых правилах не является обычным локальным Date.now(). Сеть должна использовать воспроизводимые основания проверки, включая предусмотренное медианное время блоков там, где это требуется. Нельзя считать, что изменение часов сервера библиотеки ускорит допустимость.
Возраст выхода
Относительные ограничения задают требуемый интервал от включения предыдущего выхода. BIP 68 определяет интерпретацию определённых битов nSequence для соответствующей версии транзакции. BIP 112 предоставляет скриптовую проверку OP_CHECKSEQUENCEVERIFY.
Возьмём выход, включённый в условный блок на высоте 200. Для прикладного объяснения пусть требуется возраст в десять блоков. Если выход появится позже, отсчёт также сдвинется. Это отличает относительный механизм от абсолютного условия, заданного фиксированной высотой вне зависимости от рождения выхода.
Точная граница допустимости определяется спецификацией и расчётом finality, включая возможные особенности «до» и «после». В учебной модели не будем подменять её непроверенной командой «добавьте десять и отправьте». Перед будущим запуском нужно сверить конкретный скрипт и встроенную диагностику выбранного узла.
Две шкалы
В относительном механизме различают интервалы по блокам и по времени с предусмотренной гранулярностью. Для интервала времени используются определённые сетевые правила, а не обещание точного количества секунд настенных часов. Средний интервал блока не превращает десять блоков в гарантированные сто минут.
| Механизм | Основание | Что меняется при более позднем создании выхода |
|---|---|---|
| Абсолютное условие | Заданная высота или время | Сама заданная граница сохраняется |
| Относительное условие | Возраст после включения | Точка начала отсчёта сдвигается |
| Срок счёта сайта | Серверная политика предложения | Меняется прикладная классификация оплаты |
Последняя строка особенно важна для оплаты курса. Истёкший счёт не создаёт сетевого запрета перевести средства на его адрес. Если библиотека хочет отказаться от нового предложения после срока, она меняет коммерческую модель и дальнейшие действия, а не исчезновение ранее выданного адреса.
Альтернативные пути
Временное условие может относиться только к одной ветви политики. Например, два сотрудника совместно могут расходовать раньше, а резервный путь становится доступен позднее. Фраза «средства заблокированы до даты» будет неверна, если существует другой немедленный путь.
Поэтому досье кошелька должно описывать все разрешённые ветви, участников и условия. Для восстановления важно сохранить не только ключи, но и скрипт или дескриптор. Потеря информации о резервной ветви может сделать технически доступный путь практически неизвестным оператору.
При проектировании нельзя создавать путь, который зависит от неопределённой готовности всех сотрудников спустя годы, если цель — аварийное восстановление. Нужно рассмотреть потерю ключа, отсутствие участника и изменение организационной роли. Скрипт обеспечивает установленное правило, но не гарантирует, что люди смогут выполнить его в будущем.
Полезный результат модели
Запишем для каждой временной ветви четыре поля: тип шкалы, исходную точку, требуемое условие и необходимые подписи. Затем отдельно сохраним правило срока платёжного предложения. Такое описание позволяет читателю увидеть, какие ограничения проверяет сеть и какие — сервер.
Для будущего эксперимента нужны случаи до границы, на её точном условии и после; они описываются как ожидаемые, поскольку сейчас исполнения нет. Нельзя считать одну успешную отправку достаточной проверкой всех путей.
Воздействие реорганизации на возраст
Относительное условие опирается на положение выхода в выбранной истории. Если блок его создания меняется после реорганизации, расчёт возраста должен следовать новому положению. Сервер не может продолжать отсчёт только от ранее сохранённой высоты, игнорируя хеш блока. Это ещё один пример связи временной модели с сетевым наблюдением. Восстановительное досье хранит условие как правило, а конкретный возраст вычисляет по актуальным данным. Настенные часы оператора полезны для журнала работы, но не заменяют проверяемую точку рождения выхода.
Официальные механизмы заданы в BIP 65, BIP 68, BIP 112 и BIP 113. Результат урока — точная классификация времени, необходимая для дальнейшей политики кошелька и Lightning.