Как начальное число из 24 слов может знать, когда я добавлял или удалял кошельки позже?

Поскольку у меня нет 50 очков репутации, мне пришлось опубликовать свой вопрос таким образом!

Это ответ https://bitcoin.stackexchange.com/users/56917/rstack на вопрос « Как хранятся резервные копии Ledger? »

«Использование слов для резервного копирования кошельков — это процесс, описанный в BIP 39.

По сути, мнемоника преобразуется в семя. Это начальное число затем используется в качестве начального значения для иерархического детерминированного (HD) кошелька, как указано в BIP 32. Начальное значение используется для создания главного расширенного закрытого ключа, из которого могут быть сгенерированы все остальные закрытые ключи. Генерация дочернего ключа соответствует стандарту BIP 44, поэтому он совместим и с другими кошельками.

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


Когда я впервые запускаю свой Ledger, я получаю сгенерированное начальное число из 24 слов. На данный момент в моем Ledger есть кошельки по умолчанию (BTC, ETH, LTC), если таковые имеются. Из ответа Rstack я понимаю, как это работает или может работать до сих пор, НО как мое семя из 24 слов узнает будущее, когда я добавляю или удаляю кошельки? Семя из 24 слов не меняется после добавления или удаления кошельков. Случайно сгенерированные открытые и закрытые ключи, которые будут созданы в будущем, никоим образом не могут быть связаны с ранее сгенерированным начальным числом из 24 слов. Не имеет смысла!

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

Кто-нибудь может пролить свет на это? Заранее спасибо и всем привет.

Ответы (3)

Я не знаю конкретно о Ledger, но для HD-кошельков в целом закрытые и открытые ключи не генерируются случайным образом. Скорее, они генерируются детерминированным алгоритмом из начального числа (в данном случае 24 слов). Так что они абсолютно «привязаны» к семени.

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

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

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

Да, теперь это имеет смысл! Я всегда думал, что семя генерируется для леджера, а не для создания ключей. Круто, спасибо, Нейт.

Короткий ответ: весь процесс от слов до производных закрытых ключей и адресов полностью детерминирован. См. шаги ниже для более подробной информации.

Энтропия в мнемонику

Например, процесс для мнемоники из 12 слов, совместимой с BIP39, заключается в том, что сначала (в идеале) генерируется случайное двоичное число длиной 128 бит с помощью криптографически безопасного процесса, затем вычисляется детерминированная контрольная сумма, беря первые 4 бита . хеш-дайджеста SHA256 из 128 бит, отформатированного как массив байтов.

Затем у нас есть 132 бита, которые разбиты на 12 групп, каждая из которых указывает на слово в индексе 2^11 слов (всего 2048).

Мнемоника для семени:

Эти 12 слов представляют собой корневое начальное число, которое затем передается в хеш-функцию HMAC-SHA512 (с 2048 раундами), а крайние левые 256 бит 512-битного хеш-дайджеста являются мастер-закрытым ключом, тогда как крайние правые 256 бит 512-битный дайджест хэша — это основной код цепочки, соответствующий BIP32 для иерархических детерминированных (HD) кошельков .

Расширенные ключи (xPub/xPrv):

Главный закрытый ключ используется в качестве закрытого ключа эллиптической кривой для вычисления главного открытого ключа, который составляет 264 бита.

Цепной код вместе со значением индекса, начинающимся с 0, — это то, что позволяет вам итерировать процесс деривации, чтобы каждый раз создавать (и, таким образом, расширять) другую дочернюю пару закрытый-открытый ключ по мере изменения значения индекса, в то время как цепной код остается постоянным. (как энтропия).

Производные дочерние закрытые-открытые ключи:

Этот процесс работает следующим образом: родительский открытый ключ объединяется с родительским чейнкодом вместе со значением индекса и снова передается в функцию HMAC-SHA512, где 512-битный вывод представляет собой объединение дочернего закрытого ключа и дочерней цепочки. код (где закрытый ключ используется для вычисления дочернего открытого ключа).

HMAC-SHA512(xPub+Chaincode+index0) = (512bits= child_privatekey_0 || childchaincode0)

childprivatekey_0 * Secp256k1 Generator point = childpublickey_0

HMAC-SHA512(xPub+Chaincode+index2) = (512bits= child_privatekey_1 || childchaincode1)

childprivatekey_1 * Secp256k1 Generator point = childpublickey_1

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

Таким образом, мнемоника невероятно удобна по сравнению с необходимостью хранить столько разных закрытых ключей, поскольку мнемоника позволяет воссоздать все производные ключи и даже может поддерживать несколько криптовалют с использованием BIP44 . Мне нравится называть мнемонику криптохранилищами, а не кошельками, поскольку они содержат несколько кошельков и, возможно, несколько учетных записей (криптовалют). Однако компромисс безопасности заключается в том, что все ваши активы могут быть привязаны к одной потенциальной точке отказа, если мнемоника не защищена/не получена должным образом. Таким образом, у пользователей обычно есть несколько мнемоник, например, для горячих кошельков и других для холодного хранения.

Таким образом, у него изначально нет способа узнать, создали ли вы, скажем, кошелек LTC или нет. Но он использует seed, derivation pathи , gap limitчтобы увидеть, есть ли какие-либо адреса вниз по кривой открытого ключа, которые были использованы. Если они есть, то он пометит кошелек как активный.

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

Как только вы восстановите начальное число, программное обеспечение кошелька начнет перебирать открытый ключ + путь деривации, чтобы найти все транзакции в кошельке этой криптовалюты. Это, вероятно, приведет к утечке некоторых ваших адресных данных в обозреватель/полный узел, который они используют, потому что вы просто обращаетесь к адресу за адресом и запрашиваете баланс. НО ОН НЕ ПЕРЕДАЕТ ВАШ ЧАСТНЫЙ КЛЮЧ, и у вас создается впечатление, что кошелек всегда знал, какие криптовалюты у вас там были.

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

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