При восстановлении HD Wallet откуда кошельки узнают, какие адреса восстанавливать

Я читал предложение BIP32, объясняющее, как работает HD, но в нем ни разу не упоминалось, как один кошелек в одном телефоне может восстановиться из простого мнемонического семени.

  1. Он просто пробует все возможные адреса, связанные с мастер-ключом этого семени, выполняя поиск адресов во всей цепочке блоков одновременно? (Это кажется непрактичным ИМО).

  2. Существуют ли стандарты максимального n-го адреса для генерации со стороны кошелька?

Ответы (1)

Он просто пробует все возможные адреса, связанные с мастер-ключом этого семени? (Это кажется непрактичным ИМО).

Нет, на самом деле это невозможно сделать, поскольку существует фактически бесконечное количество адресов, которые могут быть сгенерированы из одного главного закрытого ключа.

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

Большинство кошельков следуют спецификации BIP 44 для путей получения.

Существуют ли стандарты максимального n-го адреса для генерации со стороны кошелька?

Нет. Обычно кошельки генерируют адреса до тех пор, пока не будут сгенерированы nнеиспользуемые адреса (известный как предел пропусков). Лимит гэпа не стандартизирован, и многие кошельки позволяют его настроить. Во многих кошельках лимит гэпа составляет 20 ключей, однако этого, вероятно, недостаточно при восстановлении. В других кошельках это может быть 100 ключей, а в других 1000.

Отличный ответ. У меня есть пара вопросов: 1. Означает ли это, что для каждого расширенного закрытого ключа разработчик программного обеспечения кошелька может ожидать восстановления от 20 до 1000 адресов при разработке нового программного кошелька. 2. Разве это не может быть ограничением, когда идея хранить ключи локально и размер смартфона с сотнями тысяч сгенерированных расширенных закрытых ключей? Еще раз спасибо за ваш ответ.
1. Да. 2. Нет, ключи могут генерироваться динамически и их не нужно хранить. Кроме того, они очень маленькие и требуют сотни тысяч ключей, чтобы добраться куда угодно, занимая действительно заметное количество места.
Обычно кошельки генерируют адреса до тех пор, пока не сгенерируют n неиспользуемых адресов . Означает ли это, что программный кошелек должен выполнить полное сканирование цепочки блоков, чтобы проверить, не используется ли адрес?
Да, кошельки должны будут сканировать блокчейн. Однако полное повторное сканирование каждого закрытого ключа не требуется, поскольку люди обычно используют адреса по порядку. Это означает, что можно использовать то же повторное сканирование и использовать новые ключи, сгенерированные как старые. Маловероятно, что вновь сгенерированные ключи будут использоваться раньше, чем ключ, который уже был известен, особенно если предел пробела велик.
Пожалуйста, позвольте мне обобщить мое понимание здесь, вы скажете мне, что я все еще понимаю что-то не так. Насколько я понимаю, эти проблемы решаются с помощью расширенного закрытого ключа, посетите адреса братьев и сестер от индекса 0 до n, если вы обнаружите пробел в 20 адресов, мы углубимся еще в одну генерацию адресов, начиная с детей 0-го ребенка, и повторяем то же самое до пробел заполняется на уровне поколений с точки зрения дерева? Если ~ 20 - это предел разрыва от адресов братьев и сестер, что считается пределом разрыва между родительскими и дочерними отношениями?
Ограничение зазора применяется только к родственным ключам. Между родительскими и дочерними ключами нет предела промежутка. Мы не ищем все более и более глубокие уровни, мы ищем не более двух уровней, при этом предполагается, что начальная точка соответствует стандартному пути вывода. Например, если мы предположим, что BIP 44, мы начнем с ключа m/44'/0'/0'/0/0. Мы также будем искать m/44'/0'/0'/1/0. Однако мы не ищем никаких других уровней.