Мультиподпись Bitcoin 2 из 3: модель кошелька
Один приватный ключ создаёт простую модель управления, но может быть неудобен для организации. Библиотека хочет, чтобы выручку могли расходовать любые два из трёх сотрудников. В уроке разберём политику порога, её доступность и данные восстановления. Мы не создаём реальный multisig-адрес и не размещаем под ним средства.
Участники обозначены A, B, C. Политика относится к сетевому разрешению расходования. Коммерческое согласование возврата остаётся отдельной заявкой, как в предыдущем уроке.
Порог задаёт условие
Политика «2 из 3» означает, что расходование должно удовлетворить правилу с двумя подходящими подписями из предусмотренного набора. Она не означает, что любой сотрудник может самостоятельно отправить деньги, а потом получить одобрение остальных задним числом.
В объясняющем дескрипторе можно показать wsh(sortedmulti(2,KEY_A,KEY_B,KEY_C)). Реальные ключи, происхождение и контрольная сумма здесь не приведены. Внешняя форма и сортирование определяют конкретное условие. Если изменить тип скрипта или порядок в иной конструкции, адрес может измениться.
Данные подписантов должны быть проверены при настройке. Иначе сотрудник может сохранить собственный ключ, но согласовать политику с неправильным публичным ключом другого участника. Наличие трёх строк в конфигурации не доказывает, что все три будущих пути доступны нужным людям.
Доступность и потеря
При потере одного секрета остаются две подписи, достаточные для обычного расходования. При потере двух может исчезнуть возможность выполнить порог. Это свойство политики, а не обещание автоматического восстановления.
| Доступны | Возможен обычный порог |
|---|---|
| A, B, C | Да, несколько сочетаний |
| A и B | Да |
| Только A | Нет |
| Два публичных ключа без секретов | Нет |
Таблица показывает разницу между знанием политики и владением возможностью подписать. Публичные данные нужны для наблюдения и восстановления структуры. Они не заменяют потерянные секреты. При этом секреты без полной политики тоже могут оказаться недостаточными для практического поиска и подготовки расхода.
В организационном досье определяем, где хранится материал каждого участника, как заменяется ушедший сотрудник и кто вправе инициировать переход на новую политику. Смена сотрудника не переписывает старые выходы автоматически. Для переноса средств требуется разрешённое расходование по прежней политике.
Подготовка PSBT
Наблюдающий сервер может подготовить общий пакет и передать его сотрудникам. Каждый подписант проверяет заявку, получателя, сдачу и комиссию. Две независимые подписи на неправильном переводе не делают его коммерчески правильным.
Пакет может последовательно проходить участников или собирать совместимые частичные результаты. При объединении проверяется, что они относятся к согласованному содержанию. Нельзя взять подпись A из одной версии возврата и B из другой, ожидая, что совпадение номера заявки объединит разрешения.
Порядок и форма данных зависят от типа скрипта и инструментов. Исторический CHECKMULTISIG имеет специфические требования, а новые Taproot-конструкции отличаются. Курс не предлагает вручную вставлять подписи в произвольный стек; мы используем совместимый формат и проверяем возможности выбранных программ.
Независимость участников
Три ключа на одном заражаемом веб-сервере не создают ожидаемой организационной независимости. Компрометация общей среды может сразу предоставить порог. Значение политики определяется распределением полномочий и условий, а не только числом адресов в интерфейсе.
Даже разные устройства могут зависеть от одного процесса согласования. Если все сотрудники получают подменённую заявку из одного канала и слепо нажимают «подписать», порог защищает лишь от части угроз. Полезны независимые способы сверки назначения и понятное отображение всех выходов.
Обратная крайность — слишком сложная процедура, из-за которой сотрудники обходят её и экспортируют ключи для срочного возврата. Досье должно предусматривать рабочий маршрут обычных действий и восстановления. Без такого маршрута формально строгая политика может быть практически хрупкой.
Приватность и структура
Сложное условие может раскрывать публичную структуру участников при расходовании в зависимости от выбранного типа. Само наличие нескольких подписей не означает скрытие политики. Taproot предоставляет другие варианты представления, но не автоматически переносит любую пороговую систему в одну простую подпись.
Для текущей модели библиотека выбирает прозрачный порог ради учебного понимания. Мы фиксируем внешнюю форму дескриптора и ожидаемую доступность пар A+B, A+C, B+C. Не утверждаем, что политика протестирована во всех инструментах: исполнение ещё не проводилось.
При оценке комиссии учитываем больший объём данных конкретного пути. Пороговое расходование может отличаться от простого входа, поэтому прежний бюджет 700 не переносится без пересчёта размера. Цена курса 30 000 остаётся прикладным требованием, а стоимость управления выручкой рассчитывается отдельно.
Восстановительная опись
Каждый участник сохраняет собственный секрет по согласованной процедуре. Организация сохраняет полный публичный дескриптор, происхождение ключей, диапазоны и историю выдачи. Отдельно архивируются заявки и журнал расходов. Нельзя полагаться на единственный файл одного сотрудника как на весь процесс восстановления.
Критерий будущего локального разбора — способность подготовить одинаковое условие из сохранённого досье и выполнить каждую допустимую пару, а также ожидаемый отказ одной подписи. Сейчас это план проверки, не факт её исполнения.
Замена участника
Если сотрудник C уходит, оставшиеся A и B могут разрешить перенос на новую согласованную политику с участником D, если прежнее условие действительно позволяет их пару. После переноса новая выручка направляется на новый набор, а старые адреса продолжают наблюдаться для поздних поступлений. Изменение списка в административном интерфейсе само по себе не отзывает ключ C у старого выхода. Именно расходование и новое условие определяют переход полномочий. Этот случай полезно включить в восстановительный договор заранее, пока все необходимые участники доступны.
Дескрипторные конструкции описаны в документации Core, обмен пакетами — в BIP 174. После урока политика «2 из 3» является точным договором сетевого разрешения и восстановления. Далее рассмотрим, почему Schnorr открывает другие возможности совместной подписи, но не устраняет необходимость такого договора.