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]