Как сгенерировать несколько eth-адресов из одного приватного ключа? [дубликат]

Можно ли сгенерировать несколько разных eth-адресов из одного закрытого ключа?

Цель состоит в том, чтобы реализовать сервис JavaScript, который позволит пользователю покупать подписку с использованием криптовалюты.

С точки зрения пользователя должно показаться, что:

  • нажав на кнопку, он получит адрес eth-deposit;
  • при повторном нажатии пользователю должен отобразиться новый eth-адрес.

Как вариант рассматриваю генерацию новой учетной записи с парой публичный/приватный ключ для каждого нажатия пользователем кнопки и сохранение хешированного приватного ключа в БД. Кроме того, мне понадобится воркер, который будет прослушивать сеть и проверять блоки для транзакции на сгенерированную учетную запись. Но мне не очень нравится сохранять закрытый ключ, а также генерировать новую пару ключей...

Поэтому мне интересно, есть ли другой способ реализовать эту функцию без сохранения закрытого ключа в базе данных и без использования сторонних сервисов?

@Meshugah Спасибо за ссылку. Но там только общее объяснение того, как генерируются адреса, и ничего о множественном eth-адресе из одного приватного ключа, как и ничего об использовании JavaScript для решения моей проблемы.
Если вы прочитаете пост, вы увидите, что закрытый ключ ведет только к одному открытому ключу.

Ответы (3)

Теоретически один адрес может иметь несколько закрытых ключей ( каждый адрес Ethereum используется (теоретически) 2 ** 96 закрытых ключей? ), но на практике это не так - на практике один закрытый ключ соответствует одному адресу (открытому ключу) и наоборот.

Я не совсем понял, как вы выиграете от нескольких адресов с одним и тем же закрытым ключом в вашем сценарии.

Если вы не хотите хранить несколько закрытых ключей, один из вариантов — сохранить один «главный» закрытый ключ, а затем просто добавить к нему случайные строки («соль» в криптографических терминах) для создания разных адресов и просто сохранить значения соли.

Спасибо за совет. Это очень интересная идея о добавлении соли к «главному» закрытому ключу для создания eth-адреса. Это может позволить мне обойтись без использования сторонних сервисов или библиотек.
@Lauri, Биткойн также не позволяет «сопоставлять несколько адресов с одним и тем же закрытым ключом», это необходимо для такого сопоставления, поскольку для каждой транзакции используется новый адрес. наличие нескольких UTXO требует использования нескольких адресов, а не наоборот. Пожалуйста, отредактируйте свой ответ, чтобы отразить то же самое.
Спасибо за комментарий @Meshugah. Теперь я удалил биткойн-часть, так как это действительно не моя сильная часть :) Также добавлена ​​теоретическая информация о нескольких закрытых ключах.

Один из способов — использовать детерминированный иерархический кошелек (первоначально из Биткойн BIP-32 ), например, Light Wallet, см. соответствующий вопрос здесь . Таким образом, закрытый ключ становится «главным» закрытым ключом, из которого можно получить различные дочерние ключи. Таким образом, в БД необходимо сохранить только путь вывода, но не фактические дочерние ключи.

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

Спасибо. Я попробую этот подход. Надеюсь, это сработает для меня.

Расширение ответа Лаури :

Поскольку оба варианта (закрытый ключ > открытый ключ > адрес) являются детерминированными, у вас не может быть более одного адреса из одного закрытого ключа.*

Альтернативой является получение дополнительных закрытых ключей из главного закрытого ключа с заданным правилом вывода. Эти дополнительные закрытые ключи, очевидно, соответствуют новым адресам. Этот тип управления адресами называется иерархическим детерминированным кошельком/HD-кошельком .

Вы эффективно настраиваете: главный закрытый ключ > закрытые ключи (у вас может быть несколько сгенерированных > открытый ключ > адрес

есть идеи, как это реализовать?
Проголосуйте за ответ, пожалуйста. Вот реализация: github.com/Meshugah/ERC20-CommonGasWallet
у этого решения очень мало документации. вообще не понятно что он делает
Конечно, но при одном условии. Плохо объяснять в комментариях на Stack, но давайте нарушим некоторые правила, чтобы помочь сообществу.
Я положу объяснение здесь, просто обещаю отправить PR в репо с этой информацией или модулировать так, как вы считаете нужным.
Ответ Линмао неверен. Для этого вам все равно понадобятся положения модели UTXO (структура кошелька биткойна).
То, что я сделал, на самом деле довольно просто, есть что-то, называемое фабричным шаблоном проектирования, поэтому для архитектуры я просто запускаю смарт-контракт, который может динамически создавать смарт-контракты во время выполнения. Это фактически дает вам кошелек (закрытый ключ), который содержит газ, и адреса дочерних кошельков, которые могут использовать тот же газ.
Я бы хотел представить это / или не видеть, что каждый пользовательский кошелек — это то, что вы пытаетесь решить, и это работает там. За развертывание каждого адреса/кошелька/контракта взимается плата, так как это функция, выполняемая во время выполнения. Если вы можете узнать эту стоимость, дайте мне знать, пожалуйста, чтобы мы могли ее задокументировать.
Надеюсь, это было полезно. Дайте мне знать, если вы это сделаете, просто отметьте меня здесь, чтобы я получил уведомление по электронной почте, пожалуйста.