Collaborative Custody — це організація зберігання, за якої власник та інша людина або сервіс разом захищають біткоїни. У поширеній моделі власник має достатньо ключів для самостійного платежу, а сервіс допомагає в разі проблем. Така незалежність має випливати з правил гаманця, а не лише з назви продукту.
Петро керує своїми біткоїнами за допомогою власного гаманця. Проте боїться втратити пристрій або резервну копію. Гаманець — це застосунок або пристрій для отримання й надсилання біткоїнів. Підписати тут означає за допомогою приватного ключа, секретного числового значення, створити перевірний доказ дозволу на платіж. Інші можуть перевірити підпис, не знаючи цього секрету. Unchained описує модель 2-of-3: потрібні підписи двох із трьох ключів. Петро має A і B, сервіс — C. Працюють A+B, A+C та B+C; самого C недостатньо. Вимога кількох підписів називається Multisig. Петро може платити без сервісу й отримати допомогу, якщо втратить один ключ. Два пристрої, відновлені з однієї Seed Phrase — словесної резервної копії, — не є незалежними: розкриття спільного секрету загрожує обом. [1] [4] [8]
Поки Петро має працездатні A+B і повні дані гаманця, сам по собі збій сервісу не позбавляє його можливості платити. Якщо лишився тільки A, для A+C потрібен сервіс. Його збій або відмова підписати можуть зупинити відновлення. Якщо втрачено A і B, сам C не врятує. Тому незалежний вихід і відновлення з допомогою перевіряють окремо. Інструкція Casa щодо відновлення без її інфраструктури також прямо передбачає недоступність ключа сервісу. Процедура та обладнання залежать від продукту; слово «collaborative» їх не визначає. [1] [6]
Петро має копії, але іншій програмі ще треба знати, який гаманець відтворювати. Для звичайного 2-of-3 потрібні публічні ключі всіх трьох учасників, включно із сервісом, і правила їх використання. Публічні ключі перевіряють підписи, приватні їх створюють. Output Descriptor — машинозчитуваний опис конфігурації, зокрема способу отримання адрес. Дві власні копії Seed Phrase не відновлять відсутній публічний ключ постачальника. Петро зберігає та перевіряє експорт, поки сервіс працює. Перед передаванням комусь перевіряє вміст: загальний формат descriptor може містити й приватні ключі. [4] [5]
Координатор збирає дані транзакції; підписувач має ключ, яким її схвалює. PSBT, формат із BIP 174, передає незавершену транзакцію та потрібні дані між програмами й пристроями. Створення файлу не додає відсутнього підпису. Навіть без ключа координатор може зашкодити, запропонувавши іншого одержувача. До підписання слід перевірити адресу, суму, комісію та change — залишок, що повертається у власний гаманець. Hardware Wallet допомагає відокремити ключ від комп’ютера; важливо й те, що дозволяє перевірити її екран і що Петро насправді підтверджує. [2] [3]
Помилка можлива ще до першого платежу, під час створення спільного гаманця. BIP 129 описує обмін ключами та конфігурацією, щоб учасники порівняли поріг підписів, склад ключів і першу адресу. Сюди входять тип скрипту, тобто запису умов витрачання, та шляхи деривації, за якими обчислюються наступні ключі. Підмінені налаштування можуть спрямувати надходження сторонній особі. Однак документ не охоплює захищеність сховища пристрою або подальшу перевірку адрес отримання та change. Підтримка стандарту не підтверджує безпечність усього виробу. [2]
XPUB — розширений публічний ключ, з якого обчислюють публічні ключі певної гілки гаманця. Знання цих даних і конфігурації може дозволити постачальнику стежити за адресами та платежами, навіть без достатніх підписів для витрачання. Прив’язка до облікового запису з ім’ям клієнта додає ще один зв’язок. Приватність і право витрачати — різні питання. Твердження, що сервіс не може платити сам, теж має умови: він може отримати інший ключ Петра або обманом схилити його до шкідливого підпису. Менші повноваження зменшують деякі ризики, але не всі. [2] [4]
Петро втрачає ключ і створює новий у застосунку. Це не скасовує старий для попередніх надходжень. Вихід транзакції — це запис суми й умов, за яких її згодом можна витратити. Попередні надходження існують як UTXO — невитрачені виходи транзакцій із власними умовами витрачання. У звичайному Multisig потрібно створити нові умови й переказати під них відповідні кошти підтвердженою транзакцією. Після цього перевіряють залишки на старих адресах. Зміна пароля облікового запису або назви ключа не замінює переказу. Конфігурацію та родинні інструкції теж треба оновити, інакше спадкоємці отримають план, що вже не відповідає дійсності. [4] [9]
Корисна репетиція відбувається на окремому тестовому гаманці. Петро імпортує збережену конфігурацію до сумісної програми, порівнює адреси й перевіряє підписання власними ключами без початкового сервісу. Режим watch-only показує адреси та баланс, але не доводить здатності підписати. Caravan — відкритий координатор; підтримку конкретного формату й пристроїв треба перевірити. До репетиції належать також допомога у відновленні, недоступний ключ, комісії та change. Результатом має бути зрозуміла записана процедура з версіями програм, а не лише спокій від побаченого балансу. [3] [6] [7]
Для повної картини прочитайте також Multisig, Самостійне зберігання, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. На цю статтю також посилаються Bitcoin Inheritance Plan, Institutional custody.