Nockchain-wallet Key Persistence for Mining & Backup, Recovery

General
1

Hi Nockchain Team,

I’m setting up my Nockchain follower nodes and have been testing nockchain-wallet keygen. The debug output indicates that key material is persisted locally (e.g., in ~/.nockapp/wallet/wallet/checkpoints/*.chkjam).

My goal is to generate a wallet once, obtain the public key for mining and the private key for secure backup , and ensure this wallet setup can reliably persist through Nockchain software updates and potential system changes.

I have a few questions regarding this:

  1. nockchain-wallet keygen and persistence:

  • The keygen command outputs a “New Public Key” and “New Private Key” in base58 format to the console. It also appears to save wallet state to ~/.nockapp/wallet/wallet/.

  • Question: Is the primary “source of truth” for the wallet the data within ~/.nockapp/wallet/wallet/, or are the base58 private/public keys output to the console sufficient on their own for a full wallet backup and restore if the ~/.nockapp/wallet/wallet/ directory were lost?

  1. Using keys for mining & backup:

  • For configuring the miner, I would use the “New Public Key” output by keygen.

  • For backup, I would securely store the “New Private Key” output by the keygen command.

  • Question: Is this the intended workflow? Are these console-outputted base58 keys considered the definitive representations for external use and manual backup?

  1. Wallet recovery/import after updates or data loss:

  • If the ~/.nockapp/wallet/wallet/ directory is accidentally deleted or needs to be restored on a new machine (e.g., after a Nockchain update that requires a clean data directory):

    • Question : Which nockchain-wallet command should be used to restore full wallet functionality if I only have the base58 private key that keygen initially displayed? Would nockchain-wallet import-keys --input path/to/keys.jam be appropriate, and if so, what would be the content/format of keys.jam if I’m creating it from my backed-up base58 private key?

    • Or, is the recommended recovery method to back up and restore the entire ~/.nockapp/wallet/wallet/ directory?

  1. Interaction with nockchain-wallet import-keys --input path/to/keys.jam:
  • Question: If I use import-keys, does it replace the existing keys in ~/.nockapp/wallet/wallet/ or add to them? This is important for understanding how to manage wallet state if, for example, I were to import keys from another source.

Essentially, I’m looking for the most robust and recommended way to generate keys for mining, securely back up the necessary key material and reliably restore/re-import this key material to a functioning nockchain-wallet (and subsequently for mining) if the local wallet data files are lost or need to be recreated, especially considering potential breaking updates.

Thanks for any help.

1 Like
2

I’m definitely interested in this myself. Additionally, I’d love to know how one obtains the seed phrase when generating a wallet or afterwards, as nockchain-wallet seems to support “gen-master-privkey” from a seed phrase.

1 Like
3

Use the following nockchain-wallet commands.

  • show-seedphrase – prints the seed phrase of the current master keypair
  • show-master-pubkey – prints the pubkey of the current master keypair
  • show-master-privkey – prints the pubkey of the current master keypair

Delete the wallet state. I’m not sure if that’s just the checkpoints or the whole dir.

Try recovering your wallet with:
nockchain-wallet gen-master-privkey --seedphrase "your seed phrase here"

Verify that the first three commands print the same output as before.

If there are debug messages cluttering your terminal, prefix the commands with RUST_LOG=info.

2 Likes
4

Tried the commands and tested successfully. Thank you!

1 Like
5

I’m assuming that the miner doesn’t need to have any private keys in storage, that the only thing it needs to do is get the argument currently stored in the makefile to point at the pubkey of your choosing.

Generate once, verify on a different machine that the pubkeys match, and you should be good to go without putting unnecessary keys on a worker server.

6

We can’t easily verify this yet, but it would be a sensible design.