Меня смущают детские открытые ключи HD. Верен ли этот сценарий?
будут ли все адреса связаны с мастер-приватным ключом? или из-за того, что я использовал случайные индексы (шаг 5), он отключен от основного закрытого и открытого ключа? Проще говоря, достаточно ли использовать закрытый ключ (шаг 3) в биткойн-клиентах, таких как Electrum, для доступа ко всем адресам, сгенерированным с использованием дочерних публичных ключей (а не главного ключа)?
Прежде всего, вы должны генерировать дочерние адреса постепенно, а не случайным образом, так как кошельки будут генерировать их повторно, начиная с индекса 0, увеличивая индексы до тех пор, пока они не начнут находить пустые адреса.
Из главы «Обнаружение учетной записи BIP44 »:
Когда основное начальное число импортируется из внешнего источника, программное обеспечение должно начать обнаруживать учетные записи следующим образом:
- получить узел первой учетной записи (индекс = 0)
- получить узел внешней цепочки этой учетной записи
- сканировать адреса внешней цепочки; соблюдать предел зазора, описанный ниже
- если во внешней цепочке транзакций не найдено, остановить обнаружение
- если есть какие-то транзакции, увеличьте индекс счета и перейдите к шагу 1
Ограничение пропусков адресов
Предел пропусков адресов в настоящее время установлен на 20. Если программа обнаруживает 20 неиспользуемых адресов подряд, она ожидает, что за этой точкой нет используемых адресов, и прекращает поиск в цепочке адресов. Мы сканируем только внешние цепочки, потому что внутренние цепочки получают только монеты, поступающие из связанных внешних цепочек. Программное обеспечение кошелька должно предупреждать, когда пользователь пытается превысить лимит пропусков во внешней цепочке, создавая новый адрес.
Если вы генерируете свои дочерние ключи по случайным индексам, скорее всего, первые 20 индексов будут пустыми, поэтому кошелек остановит обнаружение и покажет вам пустой кошелек.
Стандартный путь получения (определенный в вышеупомянутом стандарте BIP44) следующий (M обозначает главный закрытый ключ):
m/цель'/coin_type'/account'/change/address_index
Большинство реализаций кошельков (заметным исключением является Electrum) следуют этому стандарту. Это означает, что для данного адреса получателя вы должны использовать такой путь вывода:
m / 44' / 0' / 0' / 0 / 0
Что переводится в команды bx следующим образом:
cat m | bx hd-private --index 44 --hard \ | bx hd-private --index 0 --hard \ | bx hd-private --index 0 --hard \ | bx hd-private --index 0 \ | bx hd-private --index 0 Поскольку первые три уровня предполагают усиленную деривацию, вы должны использовать главный закрытый ключ. Главный открытый ключ можно использовать только для незащищенных путей деривации.
Electrum не реализует полный стандарт BIP44, поскольку поддерживает только кошельки с одной учетной записью. В Electrum путь деривации выглядит следующим образом:
m / change / address_index
Поскольку на уровне учетной записи нет надежной деривации, вы также можете импортировать главный открытый ключ в Electrum. Это похоже на цепочку, которую вы описали, но есть дополнительный уровень «изменения».
Electrum также может импортировать главный закрытый ключ BIP44 (в диалоговом окне импорта есть флажок), заставляя вас выбирать индекс учетной записи во время импорта.
Я предлагаю придерживаться стандарта BIP44, поскольку его можно будет импортировать другими кошельками (например, Mycelium) в качестве HD-кошелька, а также он будет работать в Electrum, если вы не забудете импортировать его как ключ BIP44.
Однако, если вам нужно работать исключительно с мастер- публичными ключами, вы все равно можете использовать двухуровневую деривацию и импортировать их в Electrum. Я не уверен, что другие кошельки поддерживают их импорт.
Питер Уилле
Макс