3

Is it possible to generate different multiple eth-addresses from one private key?

The goal is to implement a JavaScript service that will allow a user to buy a subscription using cryptocurrency.

From the user perspective, it should appear that:

  • by pressing a button he will get an eth-deposit address;
  • by pressing one more time a new eth-address should be displayed to the user.

As an option, I am considering the generation of a new account with public/private key pair for each time a user presses the button and saving the hashed private key into the database. Also, I would need a worker, that will be listening to the network and checking blocks for the transaction to the generated account. But I don't really like saving the private key as well as generating a new key pair...

So I wonder if there is any other way to implement this feature without saving private key into the database and without using third party services?

| improve this question | |
  • @Meshugah Thanks for the link. But there is only a general explanation of how the addresses are generated, and nothing about multiple eth-address from one private key, as well as nothing about using JavaScript to solve my problem. – Taras Jul 3 '18 at 11:02
  • If you read the post, you'll see that a private key only leads to one public key. – Nicolas Massart Jul 3 '18 at 18:01
1

In theory one address can have multiple private keys (Is each Ethereum address shared by (theoretically) 2 ** 96 private keys?) but in practise this is not tha case - in practise one private key corresponds to one address (public key) and vice versa.

I did not quite understand how you would benefit from multiple addresses with the same private key in your scenario.

If you don't want to store multiple private keys, one option is to store one 'master' private key and then just append random strings to it ("salt" in cryptographic terms) to generate different addresses and just save the salt values.

| improve this answer | |
  • Thanks for the advice. That's very interesting idea about appending a salt to 'master' private key to generate an eth-address. This could allow me to go without using 3rd party services or libraries. – Taras Jul 3 '18 at 11:11
  • @Lauri , Bitcoin doesn't 'allow for multiple addresses to map to the same private key either' it is necessary for a mapping like such since a new address is used per transaction. having multiple UTXOs necessitates the use of multiple addresses and not the other way around. Please edit your answer to reflect the same. – Vignesh Karthikeyan Jul 3 '18 at 15:09
  • 1
    Thanks for the comment @Meshugah . I now removed the Bitcoin part as it really isn't my strong part :) Added also theoretical info about multiple private keys. – Lauri Peltonen Jul 3 '18 at 16:04
3

One way is to use a deterministic hierarchal wallet (originally from Bitcoin BIP-32), e.g. the Light Wallet, see a related question here. In this way, the private key becomes the "master" private key, which can derive different child keys. In this way, only the derivation path needs to be saved in DB, but not the actual child keys.

For monitoring transactions, there is no need to save private keys. The monitor only needs to know the account's address, which is calculated from the public key.

| improve this answer | |
  • Thanks. I will try this approach. Hope it will work for me. – Taras Jul 3 '18 at 11:03
1

Expanding on Lauri's answer:

Since both derivations (private key > public key > address) are deterministic, you cannot have more than one address from one private key.*

An alternative is to derive additional private keys from a master private key with a given derivation rule. These additional private keys obviously correspond to new addresses. This type of address management is called hierarchical deterministic wallet/HD-wallet.

You are effectively setting up: master private key > private keys(you can have multiples of these generated > public key > address

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.