152 / 691INHERIT

Bitcoin Inheritance Plan

Передання bitcoin: пошук, повноваження, ключі та здійсненне відновлення

Bitcoin Inheritance Plan поєднує людей, документацію й умови витрачання, щоб наступники справді відновили кошти без ненавмисного передчасного доступу.

Bitcoin Inheritance Plan визначає, як уповноважені наступники після смерті або втрати власником здатності діяти дізнаються про кошти, отримають потрібні матеріали та виконають відновлення. Це більше, ніж файл із seed: правові повноваження, знання гаманця й технічна здатність підписати платіж є різними частинами одного завдання.

Навіть найкраща резервна копія не допоможе людині, яка не знає про гаманець. План потребує доступної відправної точки: які гаманці існують, хто координує відновлення й де починається шлях до матеріалів. Цей покажчик не мусить містити таємні ключі. Правовий документ визначає уповноважених осіб, але не створює відсутнього підпису. І навпаки, володіння ключами технічно не доводить законного права. Треба врахувати недоступність попереднього адміністратора та наступника, який не знає його звичок. [Bitcoin Design — Inheritance wallet backup]

Seed Phrase відновлює ключі, але не обов’язково описує Multisig, часові гілки чи всі рахунки. Output Descriptor описує скрипти, ключі та дані виведення. Публічний descriptor без приватних ключів дозволяє спостерігати, а не підписувати, проте розкриває фінансову приватність. Загальний формат може містити й приватні ключі, тому важливий вміст експорту. Гаманець із BIP39 passphrase додатково потребує точної passphrase. Ані PIN пристрою, ані інший дійсний, але порожній гаманець не замінять відсутніх даних. [Bitcoin Core — Output Descriptors] [Trezor — What is a passphrase?]

У Multisig 2-of-3 будь-які два уповноважені підписувачі виконують порогову умову. Якщо два наступники отримають ключі сьогодні без додаткових обмежень, вони можуть підписати сьогодні. Якщо власник має два ключі, а помічник третій, помічник не відновить кошти сам після зникнення обох ключів власника. Оцінюйте реально доступні комбінації після кожного збою, а не лише кількість копій. Копія того самого ключа не додає незалежного підпису; конфігурація теж повинна залишатися відновлюваною. [Bitcoin Design — Inheritance wallet backup] [Bitcoin Core — Output Descriptors]

CHECKSEQUENCEVERIFY за BIP 112 разом із BIP 68 може обмежувати гілку скрипту віком витрачуваного виходу. Спрощена політика «A зараз або B через 1000 блоків» затримує підпис B, а не A. Вона не перевіряє смерть, дієздатність чи законного спадкоємця. Після спливу строку B може скористатися гілкою навіть за життя A. Це відносна кількість блоків від підтвердження конкретного UTXO, а не фіксована календарна дата; фактичний час видобутку змінюється. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time]

У цій моделі UTXO, підтверджене в блоці H, можна витратити відкладеною гілкою не раніше висоти H+1000 за виконання інших умов. Новий вхідний платіж чи відкриття застосунку не обнуляє його віку. Поновлення строку вимагає витратити це UTXO в новий вихід із належною політикою й дочекатися підтвердження. Liana використовує гілки відновлення та refresh sweep. План має відстежувати всі відповідні виходи, комісії та доступність звичайного підпису, а не лише останню активність гаманця. [BIP 112 — CHECKSEQUENCEVERIFY] [BIP 68 — Relative lock-time] [Liana — Inheritance guide]

Інструкції, секрети підпису й можливий пароль розшифрування можна розподілити між різними шляхами доступу, але послідовність повинна бути здійсненною. Пароль лише в обліковому записі, відновлення якого залежить від телефону померлого, може створити циклічну залежність. Наступникам потрібні відповідальні контакти й альтернативна процедура на випадок недоступності сховища або помічника. Більше копій підвищує доступність і кількість можливих місць витоку; публічна конфігурація має інший ризик, ніж ключі негайного витрачання. [Bitcoin Design — Inheritance wallet backup]

Зрозуміла інструкція — ще не перевірена процедура відновлення. На окремому тестовому гаманці майбутній наступник повинен без пам’яті власника знайти матеріали, відтворити очікувані адреси, визначити правильну гілку й створити перевірювану тестову транзакцію. Для часової гілки перевіряють відхилення до строку та використання після нього, наприклад у regtest. Відображення балансу доводить менше, ніж здатність підписати. Така репетиція не передбачає розкриття справжніх seed або переміщення реального спадку. [Bitcoin Design — Inheritance wallet backup] [BIP 112 — CHECKSEQUENCEVERIFY]

Зміна спадкоємця, втрата ключа або нова політика підпису вимагає перевірити, де кошти насправді заблоковані. Нове ім’я в інструкції чи новий descriptor самі не змінюють старих UTXO. Для зміни on-chain умов кошти потрібно перемістити під нову політику. Після перевірки нових копій оновлюють контакти, версії інструкцій та адреси отримання. Старі адреси можуть і далі отримувати платежі, тому їх не можна просто забути. План — це підтримуваний процес, а не раз запечатаний конверт. [Bitcoin Design — Making changes]

Для повної картини прочитайте також Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, BIP39 passphrase. На цю статтю також посилаються Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.

DOC · 001Bitcoin Design — Inheritance wallet backupДокументація ↗DOC · 002Bitcoin Core — Output DescriptorsДокументація ↗DOC · 003Trezor — What is a passphrase?Документація ↗DOC · 004BIP 112 — CHECKSEQUENCEVERIFYСпецифікація ↗DOC · 005BIP 68 — Relative lock-timeСпецифікація ↗DOC · 006Liana — Inheritance guideДокументація ↗DOC · 007Bitcoin Design — Making changesДокументація ↗
Спочатку джерела · Не інвестиційна порада