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
General keystore advice request #62
Comments
Every localnet regen creates the same 15 addresses. What is used to create these 15 addresses, and how can I replicate this on my other PC? I don't want to use keytool import every time on a different PC. How to get the same 15 addresses of local also in dev and test? Where to place my own keystore without having it wiped on every regen? |
This is currently not supported, but not a bad idea.
Just a warning for future reader that the 15 addresses of the suibase localnet are not to be copied and used on public network (e.g. devnet/testnet...mainnet!?) because these private keys are "public". This is for convenience such that all the suibase installation can run automated tests with the same set of known localnet keys. The 15 addresses generated for suibase devnet/testnet/mainnet are different. They are unique and really private to every installation and can safely be used on devnet/testnet/mainnet.
Can't be done for now. regen overwrites the sui.keystore under ~/suibase/workdirs/localnet Proposed SolutionIn a suibase.yaml a user can define additional private-keys in any format. Suibase will figure out the proper conversion (and time) to add these in all the proper sui.keystore. Example suibase.yaml:
The user can put this instruction in, say, localnet/suibase.yaml but it will apply only to localnet. To apply it to all workdirs, the user can optionally put it in a new Thought for the futureEventually, this will also evolve to support allowing the user to name the private keys. The 15 default addresses already have names (see Suibase API helper docs for more info), so they can be found by-name in automated testing. Now the user will be able to also access these added address by-name. |
Thanks for the elaborate feedback. |
Sure. Will add the support for the following option: auto_key_generation: false |
So far so good with the testing, so decided to commit even if I will keep testing after the July 4th vacation. Website doc will be written after July 4th. In meantime, I am hopeful that it does what you need. === Changes to add_private_keys are applied on update/regen/start. A change to auto_key_generation is applied on regen. You can specify either in sui.keystore format (Base64 33 bytes) or wallet format (Hex 32 bytes). Example: auto_key_generation: false
add_private_keys:
- AOToawZbfMNATU6KPldYuoGQpp82BE0w5BknPCTBjgXT
- 0x126e82a77f7768a59d355eb4ceb9c1a33b3652b8896c22d6b7e0ff94cee23109 |
changed the suibase.yaml with the above settings
I'm up and running thx |
(thanks will clean-up the ones point out) It is intended that the addresses added in suibase.yaml have no sui. The thinking is that a dev specifying its own addresses is probably looking for "more" control... and that might include wanting to start with an address that has no objects. So I have decided to default to an "empty" address... and have features like pre-funding be opt-in (to be implemented later as a per address option). |
Online documentation: |
What are the best practices for managing your keystores during move development?
How to setup the same keystore for local / dev / test ? Or is this a bad idea? I think it would make life easier as you can use one pvt key which you can also add to your chrome wallet for dev and test networks.
The text was updated successfully, but these errors were encountered: