Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change options.path #2

Open
giankotarola opened this issue Feb 6, 2019 · 5 comments
Open

Change options.path #2

giankotarola opened this issue Feb 6, 2019 · 5 comments

Comments

@giankotarola
Copy link

giankotarola commented Feb 6, 2019

Thanks for this amazing library!

I have a question, it is possible to have a method to change/override the options.path value ??

@ricmoo
Copy link
Member

ricmoo commented Feb 6, 2019

For which API call? The Wallet should already allow you to override the HDNode path. Can you provide an example and background for what you are trying to do? :)

@ricmoo
Copy link
Member

ricmoo commented Feb 6, 2019

Oh! Sorry! Just realized this is not the ethers.js repo. Yes, that is a totally reasonable request. This library will be brought into the ethers.js monrepo in v5. I will add that then. :)

@ricmoo
Copy link
Member

ricmoo commented Feb 6, 2019

Ack. Actually, back to the origina post, now that I’ve re-read the repo code. Do you mean you want to be able to change the path after instantiation? In general I prefer an immuatable signer, but having something akin to connect might make sense.

Sorry for the noise.

@giankotarola
Copy link
Author

giankotarola commented Feb 6, 2019

Np @ricmoo. And yeah, It would be great to could change the path after instantiation, in that way, we will be able to get a new address by a custom options.path value.

An example could be in a web app where the user has an input to enter a custom path and load the addresses for that path.

I imagine that could be something like this:

signer.changePath("m'/44'/60'/10'/0/0").getAddress().then((address) => {
    ...
});

@ricmoo
Copy link
Member

ricmoo commented Jan 12, 2020

To do this, you will need to re-instantiate a new LedgerSigner, since it is immutable. The Signer may have already be passed into an asynchronous function, which is in the process of using it. If it used the address to compute the recipient of a token at the beginning, then had its address changed and finally submitted a transaction, you can imagine how things could get complicated (and do wrong things) very quickly.

But it is cheap and easy to create many instances. I could add a method similar to connect, which return a new instance, connected to a different provider though, if this becomes a common use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants