Расширенный публичный ключ Bitcoin позволяет вычислять публичные ключи потомков в доступной ветви и наблюдать за её адресами. Кошельки часто называют такой ключ xpub, хотя форматы экспорта могут отличаться. Обычная копия xpub не даёт возможности подписать перевод. Она может раскрыть существенно больше сведений, чем один адрес, поэтому обращаться с ней следует как с приватной финансовой информацией.
Что видно при экспорте ключа аккаунта
Представьте кошелёк, который использует отдельные ветви для получения и сдачи. Подпись остаётся на аппаратном устройстве, а публичные данные аккаунта загружены в приложение для наблюдения. Если приложение знает формат адресов и правила получения, оно может вычислять адреса обеих неусиленных ветвей. Из ключа, экспортированного только для ветви получения, вычислить соседнюю ветвь тем же способом нельзя. Охват зависит от положения ключа в дереве.
Например, выдали адрес получения с индексом 5 и затем адрес с индексом 6. Передача только одного из них позволяет увидеть операции, относящиеся к этому адресу. При передаче ключа общей ветви наблюдатель может проверить оба адреса и вычислить следующие. В обозревателе это обычно не обозначено как готовый список адресов одного владельца. Связь получается благодаря переданным данным. Сведения о личности из самого ключа не извлекаются, но внешние записи могут позволить связать его с конкретным человеком или организацией.
Почему вместе с ключом нужен формат
Один и тот же публичный материал можно использовать в разных правилах построения выходов. Кошелёк для наблюдения должен знать, какая схема используется и где в дереве находится ключ. В частности, для мультиподписи нужны условия расходов и данные остальных участников. Импорт одного xpub в программу с другими настройками может показать пустую историю, хотя средства есть. Это повод проверить сеть, тип адресов и путь, прежде чем считать резервную копию неполной.
Когда приложение предлагает дескриптор, посмотрите, из чего он состоит. Он может включать ключи, пути, тип скрипта и сведения об источнике ключа. Импортируйте только публичную версию для наблюдения и убедитесь по документации, что файл не содержит закрытых данных. Отличия описаны в разборе дескрипторов и путей получения адресов.
Какие данные нельзя объединять
Есть важное исключение из простого правила о безопасности одного xpub. В BIP32 расширенный публичный ключ родителя вместе с закрытым ключом его неусиленного потомка может позволить восстановить закрытый материал родительской ветви. Поэтому не экспортируйте отдельные дочерние закрытые ключи в ту же систему, где хранится публичный ключ аккаунта. Это отличается от ситуации, когда наблюдателю известны только публичный ключ и обычные адреса.
После утечки xpub уже полученные публичные данные отозвать невозможно. Если дальше использовать ту же доступную ветвь, наблюдатель сможет вычислять новые адреса в ней. При смене настроек сначала проверяют, что новая схема действительно использует другой набор ключей или отделённую ветвь. Само переименование аккаунта в интерфейсе ничего не меняет.
Как выбрать объём экспорта
Для разового платежа обычно достаточно адреса получения. Для сверки истории можно ограничиться известными адресами и TXID. Если нужно регулярно формировать много адресов на устройстве без возможности подписи, подойдёт отдельная публичная ветвь, при условии что ваша схема поддерживает такой экспорт. Для наблюдения за балансом всего аккаунта может потребоваться публичный дескриптор с обеими ветвями. Проверьте объём до передачи данных и отдельно решите, где будет храниться экспорт.
Чтобы убедиться, что импорт верен, сравните несколько полных адресов получения и доступные записи о выплатах с доверенным устройством. Совпадение только названия аккаунта, баланса или короткого префикса адреса слабее такой проверки.