Расширенный ключ

xpub не является публичным ключом. Это структура из 78 байт: версия, глубина, отпечаток родительского ключа, индекс дочернего ключа, 32-байтовый цепной код и сам ключ, обернутые в Base58Check, что дает строку из 111 символов. Передайте его бухгалтеру, и он сможет прочитать каждый адрес в этой ветви и каждый сатоши, когда-либо на нее поступивший, но не сможет потратить ничего.

Как это работает

Расширенный ключ существует потому, что обычный ключ не может порождать дочерние ключи. Вывод в BIP-32 хеширует цепной код родителя вместе с его ключевым материалом и индексом, а цепной код дает дополнительную энтропию, которая сохраняет дочерние ключи одного уровня несвязанными друг с другом. Уберите его, и выводить будет не из чего.

Сериализация имеет фиксированную длину 78 байт в строгом порядке: 4 байта версии, 1 байт глубины, 4 байта отпечатка родительского ключа, 4 байта индекса дочернего ключа, 32 байта цепного кода и 33 байта данных ключа. Расширенный приватный ключ дополняет свой 32-байтовый секрет ведущим нулем, чтобы обе формы занимали одинаковую ширину. Байты версии создают читаемый префикс: 0x0488B21E дает xpub, 0x0488ADE4 дает xprv, а аналоги для тестовой сети дают tpub и tprv.

С этими ключами работают две функции деривации. Публичная вычисляет нежесткие дочерние ключи из одного xpub, и именно так платежный процессор генерирует тысячи адресов для счетов на веб-сервере, где нет ничего, что можно потратить. Приватная вычисляет что угодно, включая жесткие индексы, и требует xprv.

Вы также встретите ypub, zpub и vpub. Они происходят из SLIP-0132, соглашения, которое повторно использует ту же структуру из 78 байт с другими байтами версии, чтобы указать тип скрипта. Bitcoin Core так и не принял его, а дескрипторы выходных скриптов по BIP-380 заменили эту идею должным образом, называя тип скрипта полностью, как в wpkh([1a2b3c4d/84h/0h/0h]xpub.../0/*).

Почему это важно при покупке биткоина

Расширенный публичный ключ является самым чувствительным из всего, что вас могут попросить передать и что технически не является секретом, а просьба обычно выглядит рутинной.

Существуют три законные причины экспортировать его. Настройка кошелька только для наблюдения, чтобы смартфон мог показывать баланс аппаратного кошелька. Передача самостоятельно размещенному платежному процессору ветви, из которой ему следует брать адреса для счетов. Сборка кошелька с мультиподписью, где каждый соподписант вносит свой xpub и все они нужны, чтобы позже восстановить кошелек, даже если все сид-фразы сохранятся.

Все остальное заслуживает подозрения. Ни одна биржа, обзор которой есть на этом сайте, не нуждается в расширенном ключе, чтобы отправить вам вывод; ей нужен один адрес. Агент поддержки, который просит xpub для проверки вашего кошелька, в лучшем случае собирает профиль. Тот, кто просит xprv, просит ваши биткоины, и правильный ответ состоит в том, чтобы прекратить разговор.

Раскрытие также является постоянным, и люди недооценивают это. xpub раскрывает не только сегодняшний баланс, но и каждый платеж в этой ветви, прошлый и будущий, потому что ее владелец может продолжать выводить новые адреса еще долго после того, как вы перестанете с ним общаться. Отзыва не существует. Чтобы это отменить, нужно создать новую сид-фразу и переместить каждый биткоин, заплатив комиссию по каждому входу, которым вы владеете.

Одна ловушка относится именно сюда. Если у кого-то есть ваш расширенный публичный ключ и он также получает один нежесткий дочерний приватный ключ, он может восстановить родительский расширенный приватный ключ и потратить всю ветвь. BIP-32 указывает это в своих собственных примечаниях по безопасности. Именно поэтому уровни аккаунта делаются жесткими, и поэтому экспорт отдельного ключа из современного кошелька, который некоторые инструменты все еще предлагают, является опасным удобством, а не удобной возможностью.

Что бухгалтер может и чего не может сделать с вашим xpub

Передайте расширенный публичный ключ, и граница будет резкой. Например, вы экспортируете расширенный публичный ключ аккаунта для m/84'/0'/0' из аппаратного кошелька и отправляете его по электронной почте тому, кто готовит ваши налоги.

Он сможет вывести каждый адрес для получения и каждый адрес для сдачи в этом аккаунте, проверить каждый в любом обозревателе блокчейна и восстановить полную историю сумм прихода и расхода с датами. Он сможет просуммировать ваш текущий баланс до последнего сатоши и продолжать наблюдать за его изменениями. Он сможет вывести адреса, которые вы еще не использовали, и увидеть момент, когда вы это сделаете.

Подписать он не сможет ничего. Жесткие дочерние ключи недостижимы со стороны публичного ключа, поэтому соседний аккаунт, например m/84'/0'/1', остается для него невидимым, как и мастер-ключ. Он не сможет восстановить приватный ключ ни из чего из перечисленного, если только вы отдельно не передадите ему один из отдельных ключей под ним, а это и есть тот случай отказа, который описан выше.

Расширенный ключ vs публичный ключ

Публичный ключ представляет собой точку на кривой secp256k1, 33 байта в сжатом виде, и он проверяет подписи. Расширенный публичный ключ представляет собой ту же самую точку плюс 32-байтовый цепной код и четыре поля, описывающих ее положение, и он может породить миллиарды дальнейших публичных ключей. Публикация публичного ключа раскрывает информацию об одном выходе. Публикация расширенного публичного ключа раскрывает кошелек.

Расширенный ключ vs Wallet Import Format

xprv и строка Wallet Import Format обе кодируют ключевой материал в Base58, и на этом сходство заканчивается. Строка WIF содержит один приватный ключ с байтом сети и контрольной суммой, она полезна для переноса одного устаревшего ключа, и ее импорт восстанавливает ровно те биткоины, которые заблокированы на этом ключе. xprv содержит ключ плюс цепной код и положение, которые позволяют ему воспроизводить неограниченную ветвь. Именно эта асимметрия и застает людей врасплох: перенос WIF в современный кошелек представляет собой рутинную работу, а вставка xprv в незнакомое программное обеспечение сразу передает все, что под ним находится.