Dead Man’s Switch

Модель может дать владельцу немедленную ветвь, а другим ключам — ветвь после ожидания. То же условие может возникнуть при госпитализации, потере устройства или забытом обслуживании. Технический доступ не подтверждает жизненные обстоятельства и не устанавливает законного наследника. До проектирования определите точное событие, которое система действительно наблюдает. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

deadmansswitch.net отправляет подготовленные письма после пропущенных подтверждений. Это другой уровень, чем Bitcoin Script. В собственном проекте отдельно оцените доступность аккаунта, доставку адресату и преждевременное раскрытие данных. Сообщение может указать место резервной копии, но не доказывает выполнение условий расходования. Изменением таймера нельзя отозвать отправленный seed; при утечке нужно также решить вопрос контроля над монетами. [Dead Man’s Switch — Service mechanism]

BIP 65 и OP_CHECKLOCKTIMEVERIFY проверяют абсолютный порог высоты или времени. BIP 112 и OP_CHECKSEQUENCEVERIFY вместе с BIP 68 могут обеспечивать возраст конкретного UTXO. Относительные временные блокировки используют единицы 512 секунд и median-time-past, а не часы телефона; BIP 113 описывает медиану временных меток предыдущих 11 блоков. Срок в блоках нельзя выдавать за точную календарную дату. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [BIP 65 — OP_CHECKLOCKTIMEVERIFY] [BIP 113 — Median time-past]

Если UTXO, подтверждённый в H, имеет ветвь восстановления после 1000 блоков, она может стать доступной не раньше H+1000 при выполнении остальных условий. Вход в приложение или новое поступление на другой выход не сбрасывает его возраст. Для обновления относительного срока требуется потратить этот выход и подтвердить новый с нужной политикой. Отслеживайте каждый UTXO отдельно: частичное обновление кошелька может оставить старые монеты близко к порогу. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

В модели с постоянно доступной основной ветвью ожидание не отменяет её полномочия. Добавляется доступная ветвь восстановления; кто-то всё равно должен подписать и передать транзакцию. Если обе ветви допустимы, расходование одного UTXO определяет подтверждённая транзакция, а не надпись «владелец» или «наследник» в приложении. Проект должен учитывать позднее обновление и конкурирующие траты. [BIP 112 — CHECKSEQUENCEVERIFY] [Liana — Wallet architecture]

Само nLockTime откладывает конкретную транзакцию; оно не доказывает, что уполномоченный ключ не может подписать другой платёж. Предварительно подписанный план должен определять входы, выходы, полномочия подписантов и оплату комиссии. Если другая подтверждённая транзакция потратит его вход, исходная подпись станет непригодной. Поэтому при изменении плана недостаточно исправить документ: проверьте реальные UTXO и наличие новых материалов у получателей. [BIP 65 — OP_CHECKLOCKTIMEVERIFY]

Из этих механизмов следует необходимость запаса до ближайшего срока, работающих уведомлений и средств на комиссии. Более частое обновление требует комиссий; более долгое ожидание продлевает недоступность восстановления. Восстанавливающему нужны правильные ключи, описание политики, например descriptor, и пригодный инструмент. Копия, закрытая аккаунтом или устройством недоступного владельца, создаёт циклическую зависимость. [Liana — Wallet architecture] [Liana — Signet testing guide]

Liana предлагает инструкцию для Signet. Отдельная тестовая система позволяет проверить преждевременную попытку, созревание ветви восстановления и обновление конкретного выхода. Добавьте недоставленные уведомления, потерю основного ключа и восстановление из сохранённых материалов. Проверьте, что старые ключи и UTXO всё ещё позволяют после смены получателя. Различайте подпись, принятие в mempool и подтверждение: один успешный сценарий не доказывает безошибочность всего плана. [Liana — Signet testing guide] [BIP 112 — CHECKSEQUENCEVERIFY]