Поскольку у меня нет 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 слов.
Кто-нибудь может пролить свет на это? Заранее спасибо и всем привет.
Я не знаю конкретно о 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
не совсем связано с вашим конкретным вопросом, но сколько итераций программное обеспечение будет делать перед последним известным используемым адресом. В противном случае он может остаться в бесконечном цикле, пытаясь сгенерировать все адреса, принадлежащие вашему ключу.
Бриз