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.