Bitcoin Inheritance Plan — це план передачі біткоїнів після смерті власника або втрати ним здатності діяти. Уявімо Анну: вона добре знає свій гаманець, але родина ним ніколи не користувалася. План має провести близьких від «Анна мала біткоїни» до гаманця, яким вони зможуть безпечно користуватися. Тому він охоплює інструкції, резервні копії, відповідальних людей і правові повноваження. За самостійного зберігання немає адміністратора, який просто замінить утрачені ключі. Технічний доступ і право на майно — різні речі.
Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Приватні ключі — це таємні числа, за допомогою яких можна дозволити витрачання біткоїнів. Анна дбайливо зберігає резервну копію, але нікому не каже, що вона існує. Для родини наслідок може бути таким самим, як без копії. Корисний початок — доступна для пошуку інформація про гаманці та контакт людини, яка допоможе з наступними кроками. Такий дороговказ не обов’язково містить таємні ключі. Він має пояснювати, де шукати необхідні матеріали, навіть якщо Анна нічого не може доповнити. Правовий документ може визначати, хто має отримати майно, але не створить цифровий підпис для дозволу платежу. І навпаки: здатність підписати не доводить права на майно. Правову частину слід узгодити з відповідною юрисдикцією та обставинами. [1] [8]
Seed Phrase — це резервна копія словами, з якої відновлюють таємні дані для ключів. Якщо Анна використовує passphrase BIP39, додатковий таємний текст, він теж має залишатися доступним. PIN зазвичай розблоковує пристрій; утрачену passphrase він не замінить. Інша passphrase може відкрити коректний, але порожній гаманець. Складніші налаштування потребують також конфігурації: відомостей про ключі, рахунки та умови. Output Descriptor записує цей опис для програми, зокрема дані для виведення адрес. Це особливо важливо для Multisig, де потрібно кілька підписів. Публічний descriptor без приватних ключів дозволяє спостерігати, але не витрачати. Він усе ж розкриває адреси та історію; загальний формат може містити й приватні ключі. Важливий фактичний вміст експорту. [2] [3]
Анна може розділити інструкцію, копію та пароль до зашифрованого файла. Але захист не допоможе, якщо донька мусить спершу розблокувати телефон Анни, щоб увійти в обліковий запис з інструкцією розблокування цього ж телефона. Пройдіть шлях очима людини, яка не знає ваших звичок. Їй потрібні контакти й запасний варіант, якщо помічник або сховище недоступні. Більше копій зменшує ризик утрати, але додає місця можливого витоку. Тому публічну конфігурацію й секрет, що дозволяє негайний платіж, слід захищати по-різному. [1]
Замість лише запитувати «тобі зрозуміло?» краще разом потренуватися з окремим тестовим гаманцем. Майбутній наступник за інструкцією знаходить матеріали, відновлює очікувані адреси й створює тестову транзакцію, яку можна перевірити, без підказок із пам’яті Анни. Самого балансу на екрані замало: гаманець для спостереження може показувати кошти, не вміючи підписати платіж. Якщо є часова умова, перевіряють відхилення до завершення строку та використання після нього. Блок об’єднує транзакції в пакет, який додають до спільної історії. Допоможе regtest — приватна тестова мережа з керованим створенням блоків. Перевіряють процес, не публікують справжню копію й не переміщують реальний спадок. [1] [4] [9]
Multisig 2-of-3 означає, що підписи будь-яких двох із трьох визначених ключів дозволяють платіж. Якщо двоє наступників отримають ключі сьогодні й немає додаткової умови, вони можуть підписати сьогодні. Сам поріг не знає, що платіж мав чекати спадкування. Протилежна проблема виникає, коли Анна зберігає два ключі, а помічник третій: утративши обидва ключі Анни, він не зможе підписати сам. Треба розглянути доступні комбінації й після втрати людини або пристрою. Дві копії одного ключа не дають двох незалежних підписів. Разом із ключами має зберігатися конфігурація гаманця. [1] [2]
Часове блокування відкладає певний спосіб витрачання. За правилом «Анна зараз або Борис після 1000 блоків» чекає гілка Бориса, не Анни. Гілка тут — один із дозволених шляхів до платежу. CHECKSEQUENCEVERIFY з BIP 112 разом із BIP 68 дозволяє прив’язати умову до віку UTXO: невитраченого виходу транзакції, тобто окремої суми з власними умовами. Мережа не перевіряє смерть і не визначає законного спадкоємця. Після завершення строку Борис може скористатися своєю гілкою й за життя Анни, якщо виконає решту умов. Приклад рахує блоки, не календарні дні; фактичний час їх створення змінюється. [4] [5]
Якщо UTXO з прикладу підтверджено в блоці H, відкладена гілка дозволяє витрачання не раніше блоку H+1000 за виконання інших умов. Новий вхідний платіж або відкриття програми не обнуляє вік старого виходу. Новий строк для цієї вартості починається лише після витрачання в новий вихід із відповідним правилом і підтвердження транзакції. Liana використовує гілки відновлення та refresh sweep — переказ власних коштів у новий набір виходів. Потрібно перевірити всі відповідні виходи, комісії й доступність звичайних ключів підпису. «Я нещодавно користувався гаманцем» не пояснює, які виходи справді оновлено. [4] [5] [6] [10]
Зміна наступника, втрата ключа або нові правила потребують більшого, ніж виправлення імені в інструкції. Умови наявних UTXO залишаються старими. Новий descriptor описує інше налаштування, але сам не переносить туди гроші. Зміна умов, записаних у мережі, потребує підготовки нового гаманця, перевірки копій і переказу коштів коректною транзакцією. Потім оновлюють інструкції, контакти та адреси отримання. Старі адреси досі можуть приймати платежі, тож не можна бездумно відмовлятися від їх спостереження та потрібних даних. План має працювати тоді, коли знадобиться, а не лише в день написання. [7]
Для повної картини прочитайте також Dead Man’s Switch, Multisig, Timelock, Collaborative Custody, Seed Phrase, BIP39 passphrase. На цю статтю також посилаються Shamir Secret Sharing, Bitcoin Vault, Dead Man’s Switch, Collaborative Custody.