Насколько мне известно ( и как объяснено здесь ), иерархические детерминированные кошельки хранят пару мастер-ключей (закрытый и открытый). При их использовании открытый ключ генерируется заново при каждой транзакции. Я понял, что дочерние ключи генерируются эллиптическим умножением родительских ключей. Утверждается, что преимущества, связанные с HD-кошельками:
Хотя я более или менее понимаю теоретическую концепцию, я борюсь с практической реализацией процесса и, в частности, с тем, как система связывает баланс нескольких транзакций (распределенных по разным производным открытым ключам) с одним и тем же биткойн-счетом. или главный открытый ключ?
Кто-нибудь может пояснить "для чайников"?
как система связывает баланс нескольких транзакций (распределенных по разным производным открытым ключам) с одним и тем же биткойн-счетом или главным открытым ключом?
Система должна знать XPUB (часто главный открытый ключ), чтобы сгенерировать все адреса для «отслеживания».
Пока мы говорим об основных открытых ключах и конфиденциальности, есть много вещей, которые вы можете сделать неправильно. Делиться своим главным открытым ключом (XPUB) — плохая идея, поскольку другая сторона сможет видеть все ваши адреса. Я видел много проектов, делающих это, в основном разрушающих вашу конфиденциальность.
BIP47, который все еще находится в стадии разработки и не реализован, направлен на решение этой проблемы конфиденциальности и по-прежнему предлагает преимущества бесконечных адресов HD-кошельков.
Но то, что вы описываете, действие совместного использования главного открытого ключа и предоставление КЛИЕНТУ возможности получить адреса, плохо и не имеет места в большинстве систем. Гораздо более вероятно, что СЕРВЕР получает адреса и хранит главный открытый ключ в секрете.
Итак, предположим следующее:
У нас есть открытый ключ, с помощью которого можно получить все другие новые открытые ключи (и, следовательно, новые адреса).
Мы получили одну транзакцию на адрес 15.
Мы загружаем новый узел и выполняем начальную загрузку блока, и, таким образом, обработали 0 блоков.
Мы потеряли наш предыдущий файл wallet.dat, поэтому у нас нет ни единой подсказки, на какие адреса мы получили деньги. Мы восстанавливаем наш кошелек через открытый ключ, как описано в 1.
На данный момент HD-кошелек на самом деле не знает, на какие адреса он получил какие-либо деньги, но чтобы проверить, принадлежат ли транзакции нам, он повторно сгенерировал «LOOKAHEAD» первых 20 адресов. Эти 20 потенциально используемых адресов добавляются в пул ключей, все новые транзакции на эти адреса принадлежат нам.
Блок обрабатывается с транзакцией по адресу 15, это соответствует нашему опережению 20, поэтому мы можем его подобрать. Мы повторно генерируем дополнительные адреса просмотра, когда находим транзакцию по одному из наших адресов.
Этот просмотр вперед важен, давайте предположим, что мы просмотрели вперед 10, мы не будем смотреть по адресу 15, только до адреса 10. Мы не увидим нашу транзакцию. (примечание: это применимо только в том случае, если вы потеряли свой wallet.dat и восстановили его из seed)
BIP44 определяет «ограничение пропусков адресов» равным 20.
Предел пропусков адресов в настоящее время установлен на 20. Если программа обнаруживает 20 неиспользуемых адресов подряд, она ожидает, что за этой точкой нет используемых адресов, и прекращает поиск в цепочке адресов.