Bitcoin descriptor – текстовое описание того, какие адреса принадлежат кошельку и при каких условиях средства можно потратить. Для мультиподписи в нём закодированы порог подписей, набор ключей и правила получения адресов. Ошибка в одной детали может создать кошелёк, который выглядит знакомо, но принимает деньги на другой набор условий. Поэтому descriptor стоит проверять как техническую спецификацию, а не как удобную строку для копирования.
Сначала установите, что именно описывает descriptor
Descriptor обычно задаёт тип выходного скрипта, а внутри содержит функцию вроде `multi` или `sortedmulti`, порог M и список из N ключей. Запись 2-of-3 означает, что для траты должны быть доступны любые два ключа из трёх, если именно так устроено выражение. Но название кошелька или подпись «совместный сейф» этого не доказывают: проверить надо само условие и фактические публичные ключи.
Внешняя оболочка важна не меньше порога. `wsh` описывает witness script для SegWit, `sh` может задавать вложенный скрипт, а `tr` относится к Taproot и имеет другую модель. Адреса с разными типами скриптов отличаются и по формату, и по комиссиям. Сравнивайте descriptor с тем, что поддерживает кошелёк и что ожидают участники, не заменяйте его похожей строкой из другого экспорта.
Проверьте участников, происхождение ключей и порядок
Каждый ключ в descriptor должен соответствовать заранее согласованному участнику или устройству. Сопоставьте fingerprint и путь derivation с резервной документацией кошелька, если они присутствуют. Обычно расширенный публичный ключ не даёт подписывать транзакции, но позволяет наблюдать за производными адресами; это всё равно конфиденциальная информация. Не отправляйте descriptor в публичный чат и не публикуйте его без понимания объёма раскрываемых данных.
В `multi` порядок ключей влияет на порядок элементов скрипта, а `sortedmulti` сортирует их по правилам реализации. Эти формы не следует считать взаимозаменяемыми без сверки: кошельки должны получать ту же политику и те же адреса. Сравните список xpub, отпечатки и derivation path посимвольно, включая ветвь аккаунта. Проверьте, что адреса восстановления можно воспроизвести в каждом устройстве, участвующем в схеме.
Разберите receive и change ветви
Descriptor может содержать диапазон производных ключей и разные ветви для получения и сдачи. Часто внешняя ветвь используется для receive, а внутренняя – для change; обозначения зависят от формата экспорта и соглашений кошелька. Нельзя полагаться на то, что любой импортёр автоматически поймёт диапазон одинаково. Возьмите контрольный адрес получения и адрес сдачи из интерфейса, затем выведите соответствующие индексы из descriptor.
Проверьте несколько последовательных адресов, а не только один. Убедитесь, что адреса относятся к ожидаемой сети Bitcoin, не перепутаны ветви и индекс не выходит за объявленный диапазон. Несовпадение первого адреса часто указывает на неверный путь, ключ, порядок участников или тип скрипта. На этом этапе полезно сверить материал с руководством о Bitcoin descriptors и тем, как скриптовая мультиподпись отличается от MuSig2.
Проверьте checksum и вычисленные адреса
Checksum помогает обнаружить случайную порчу descriptor при копировании. В Bitcoin Core команда `getdescriptorinfo` разбирает descriptor и возвращает его checksum. Это проверка целостности строки, а не сертификат правильности кошелька: корректно рассчитанный checksum может относиться к неверному порогу, чужому ключу или другой сети. Сравнивайте результат расчёта с доверенным источником и записывайте исходный текст вместе с контрольным значением.
Для независимой проверки используйте известную версию Bitcoin Core или совместимое средство, которому вы доверяете. Импортируйте descriptor как watch-only, если задача состоит только в проверке адресов. Сравните выведенные адреса с устройствами подписантов и заранее сохранённым резервным описанием. Не вводите seed-фразы в сайты и онлайн-конвертеры: проверка публичной политики не требует раскрытия секретных ключей.
Проведите безопасную пробу до крупного депозита
До использования убедитесь, что нужное число подписантов действительно может создать и передать транзакцию. Подготовьте небольшую тестовую транзакцию, проверьте её на всех необходимых устройствах и убедитесь, что каждый участник видит те же входы, адрес назначения и комиссию. Восстановление watch-only списка и восстановление способности тратить – разные задачи; для последнего нужны рабочие приватные ключи, резервные копии и совместимые процедуры.
Сохраните проверенную версию descriptor, checksum, схему ролей и процедуру обновления резервов в доступном участникам защищённом месте. Зафиксируйте, кто подтверждал ключи и адреса, но не записывайте рядом seed-фразы. Если изменился один ключ, путь или формат выхода, рассматривайте это как новую политику и заново проверяйте адреса. Практический контроль UTXO и комиссии пригодится перед расходованием средств.
Ошибки, которые выглядят безобидно
Частые источники расхождения – скопированный xpub другого аккаунта, неверный fingerprint, пропущенная receive/change ветвь, иной тип скрипта и перепутанный индекс. Также опасно сравнивать только визуальное начало длинного ключа: две строки могут совпадать на первых символах и различаться дальше. Сравнение должно учитывать всю структуру и проверяться машинно там, где это возможно.
Не называйте descriptor «секретом восстановления» без оговорок. Он описывает публичные ключи и правила наблюдения, а не заменяет секретные ключи. При этом его утечка может раскрыть баланс и историю адресов. Для разделения ролей смотрите и обзор multisig и MuSig2, а для общей подготовки операции – проверку UTXO и комиссии.
Итоговая последовательность проверки
Сначала подтвердите тип скрипта и M-of-N, затем сверьте ключи, отпечатки и пути. После этого проверьте receive/change диапазоны, checksum и несколько производных адресов в независимом кошельке. Перед регулярным использованием выполните небольшую тестовую трату, убедитесь в доступности нужного числа подписантов и сохраните проверенную процедуру. Каждый шаг отвечает на отдельный вопрос, поэтому успешный checksum сам по себе не закрывает аудит.
Если одно устройство показывает другой адрес, остановитесь и выясните причину до отправки средств. Не пытайтесь «исправить» расхождение, меняя descriptor наугад: можно случайно создать другую схему и потерять предсказуемость резервного восстановления. Надёжная проверка заканчивается только тогда, когда политика, производные адреса и реальная процедура подписания согласуются у всех участников.
