Issues with keychain identity management

I noticed that after using keychain -activate -id 2 to select and mine to new identity, mining rewards still get credited to old domain that was used before.
Yesterday evening when i changed to id2 the balance was 931. but now its 967: https://test.gridnet.org/api/getBalance?address=1LePAVd1JGXaYnyTQM6WPADMAZRKyPGp5D the new ID is still not registered and has no balance https://test.gridnet.org/api/getBalance?address=1AEkGFrMFmNgHB3rf8aSqCTJC5rW3F5wZB

therefore i suspect that even after changing to next id, mining rewards get credited to old ID

Thank you for your report, Operator, we are already investigating this.

@MrUnHappy does the keychain utility report proper address being activated?

Kindly provide relevant log with the exact sequence of command that you execute, within of a code block, make sure your private key is not included.

@MrUnHappy
besides the sequence of logs, once your Core begins to boot, try to find a line which looks like the one following:

[TestNet:Blockchain Manager]: Operator's State Domain ID: 1Lunw3BnraUeJoEiZc5673NbUwRGUiNiim

verify whether the reported state-domain corresponds to the one which you’ve set through keychain.

Operator, and report.

P.S before each block is formed you should also be able to see a log-line beginning with’ Operating Identity:


i was trying to activate id 2 as said in the keychain -help info.
i just recognized that logs say that there is no explicit key-chain and that it will user the default. this might explain why it still used the identity from before.
but whoami as seen in the screenshot doesnt show the balance from the one before.

@MrUnHappy
thank you for your further feedback, now
for future reference kindly copy&paste logs from Terminal into here using the
image block. All the formatting and colors would prevail and it would help referencing particular fragments as well as unable search to work across the log you’ve provided.

The no explicit key-chain notification above in your log simply says that you have not requested keychain utility to load any specific key-chain so it loaded the default - this is not only fine but anticipated.


Operator, restart Core and find the reported Operating Identity as requested above.

Thank you for your feedback.
Can you please provide a small howto, to create and use a new identity.
even keychain nextid does not seem to do it.

@MrUnHappy your command looks fine

it activated the identity above.

now all you need to do is to check whether the above identity is same as the one reported as Operating Identity during the bootstrap sequence.

thank you for clarifying.
its the same as in the line Identity.

After restarting it seems to show a totally different Identity when checking keychain -show -priv.
And also my former key isnt there anymore.
Only getkey seems to show the correct keys and identities.
Also keychain -activate -id 0 doesnt bring me back to my old identity with my existing balance.

Operator, always back up your keys before getting involved in key manipulation.

Proper use of commands as shown in MAN page could not have lead to destruction of your private key.

A proper way to activate an identity at a certain depth would be to use:
keychain -id ID_INDEX -activate

replace ID_INDEX with an identity index. As the MAN-page states, the base identity is at index 0.
To activate another additional identity, use keychain -id 1 -activate then for a yet another one keychain -id 2 -activate and so on.

If your original private key is unavailable then you must have generated and or replaced the entire key-chain.

@MrUnHappy as the documentation states - you can use the -name switch to load any key-chain even if you’ve switched to a new one. You’ve got your previous key-chain identifier in logs you’ve provided.

During the initial bootstrap sequence you should be able to see lines reassembling ones below:

 [TestNet:Blockchain Manager]: Operator's Key-Chain ID: key0
 [TestNet:Blockchain Manager]: Operator's State Domain ID: 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq
 [TestNet:Blockchain Manager]: Note: Your current ID within the network is: 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq use 'getNextID' to generate and set new ID from your key-chain at any moment.

Notice above that reportedly your main key-chain is key0 (the default).

A single key-chain may own very many sub-identities, each representing a unique State-Domain (wallet’s address for basic usage scenarios).

Now, once you run keychain -show you would see something reassembling what’s shown below:

$ keychain -show
 Use '-help' to see available options.
 No explicit key-chain requested. Attempting to load default key-chain 'key0'.
 Default key-chain 'key0' loaded.

v--[Key-Chain Data]--v
[Name]: key0
[Active Identity At Index]: 0
[Key-Chain Depth]: 2
[Active Domain]: 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq

v--[All Domains]--v
0) 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq
1) 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c

as you can see currently there’s an identity active at index 0. To be precise we have actived the sub-identity 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq from the key-chain, which is at index 0 of your key0 key-chain.

To switch identity, say to identity at index 1 we need to use:
keychain -id 1 -activate

see below:

$ keychain -id 1 -activate
 No explicit key-chain requested. Attempting to load default key-chain 'key0'.
 Default key-chain 'key0' loaded.
 State of the key0 key-chain was updated.
 Key-Chain 'key0' stored.
 Identity '1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c' activated.

now once we execute keychain -show it would report what follows:

$ keychain -show
 Use '-help' to see available options.
 No explicit key-chain requested. Attempting to load default key-chain 'key0'.
 Default key-chain 'key0' loaded.

v--[Key-Chain Data]--v
[Name]: key0
[Active Identity At Index]: 1
[Key-Chain Depth]: 2
[Active Domain]: 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c

v--[All Domains]--v
0) 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq
1) 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c

It thus successfully activated State-Domain 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c available at index 1 of your key0 key-chain.

You may have multiple key-chains.

Now, if we reboot Core, during the initial bootstrap sequence we would see what follows:

 [TestNet:Blockchain Manager]: Operator's Key-Chain ID: key0
 [TestNet:Blockchain Manager]: Operator's State Domain ID: 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c
 [TestNet:Blockchain Manager]: Note: Your current ID within the network is: 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c use 'getNextID' to generate and set new ID from your key-chain at any moment.

Worked 100%. Your new identity is active and the setting would prevail during restarts.

Operator, now if you run keychain - help you would see a plethora of explanation and additional documentation including examples.

Part of this built-in MAN-page follows:

[Arguments]:
- qr: Use a QR Intent for export which may be scanned by the mobile application.
- gen: Generate a new key-chain.
- name: Includes key-chain's name in exported data.
- store: Store the key-chain in cold storage.
- activate: Activate a key-chain as the main identity. Defaults to index 0 if not specified.
- export: Export a key-chain. Use with '-master' to export the master key.
- master: Used with 'export' to export the master key.
- name [chainID]: Name the key-chain. Defaults to 'keyX' where X is a number.
- genid: Generates the next unused sub-identity.
- id [index]: Set an active sub-identity index.
- show: Display key-chain information. Use '-priv' to include private key.
- priv: Used with 'show' to display the private key.

The getnextid GridScript command is now deprecated. The new keychain utility is your power-house for all identity and key-management needs.

Let’s use the -genid switch to generate an additional sub-identity, shall we?

$ keychain -genid
 Use '-help' to see available options.
 No explicit key-chain requested. Attempting to load default key-chain 'key0'.
 Default key-chain 'key0' loaded.
 Most recent identity at index 1. Getting new identity at index 2
 Remember to use '-activate' to actually activate this identity.
 State of the key0 key-chain was updated.
 Key-Chain 'key0' stored.
 Identity '1GSDYfFmaWhUzg3ZVr5Gn2Qde2KCHkKWuH' activated.

Operator, notice! While it generated new identity the output deliberately explains that

  • it was not activated
  • it was not saved

thus, in fact your key-chain or Core’s settings were not affected in any way!

For these settings to be effective you need to use -activate switch so the final command would be
keychain -genid -activate or at least keychain -genid -store to be able to see the activity with consecutive calls to keychain -show.

Activating an identity within of a given key-chain implicitly causes the encapsulating key-chain to be assumed as the main Operator’s key-chain as well.

Next time you run key-chain -show you would see:

$ keychain -show
 Use '-help' to see available options.
 No explicit key-chain requested. Attempting to load default key-chain 'key0'.
 Default key-chain 'key0' loaded.

v--[Key-Chain Data]--v
[Name]: key0
[Active Identity At Index]: 2
[Key-Chain Depth]: 3
[Active Domain]: 1GSDYfFmaWhUzg3ZVr5Gn2Qde2KCHkKWuH

v--[All Domains]--v
0) 159G9aduJHQ1iSRK3N4cBoJ8Nc35Vuiynq
1) 1BhQ3h9VqbXKzjWNkPhRYqTbhJZ2xiUQ7c
2) 1GSDYfFmaWhUzg3ZVr5Gn2Qde2KCHkKWuH

Hi Vega4 I hope all is well .
I have looked at the above thread and wonder if it has any relevance to the following question:
what would be the correct procedure to re connect an existing wallet address and private key held currently on the mobile app in the event of total uninstall under the self destruct procedure on Gridnet core ?
So that the key held on the mobile app can be exported, to once again be used to verify and receive mining rewards
from a totally fresh install of Gridnet core .
I would be most grateful for a reply.

May I have a reply please :pray:

Hey Jamie!

Not sure I follow, the private key held by the mobile app may be complete unrelated to the wallet used by Core and you suggest that wiping out Core would affect your mobile app in any way.

Can you rephrase yet again what you are willing to acomplish, please?

Hi CodesInChaos

Firstly thank you for getting round to replying to me I appreciate it…

What I’m trying to say in my apparent usual clumsy way is this, when I first downloaded Gridnet core I had also changed my phone so as to also be able to download the mobile app.

During this time whilst getting somewhat familiar with the phone app I am aware that I generated numerous new private/public key pairs.

Now in the article ’ a brief introductory for operators’ it is mentioned that on first download of core one may choose to export ones private key to the mobile app ,through a QR code which I believe I did, but then subsequently generated new private/public keys on the phone app as stated above.

Once I realised that I kept the last generated key which I still hold.

Whilst I continued to run core and mine this was sporadic due to development issues /possibly my systems effective capability and Gridnet core being down etc.

I haven’t run core for some time given the difficulties encountered and I wanted to do a totally clean install of core and initiate the self destruct procedure and install the latest version which was 1.4.4 .

So Codes ,what I was enquiring was whether or how I could do a totally fresh install of core and at the same time export my private key to the clean install of core, start mining again after exporting that key to core.

Thanks again !

yes, of course, this can be done.

So where is the current Master Private Key stored?

On the old Core installation I presume.

In such a case, fire up the old installation and use the keychain utility to export the Master Private Key.

You may export to the mobile app

  • through a QR Code
  • by copy& pasting the private key from old installation of Cofre

the Master Private Key exported from ‘old installation’ you may import to a ‘new’ one.

Feel invited to consult the official MAN-page built into the keychain utility by executing keychain -help

What I’ve actually been asking is this -is it possible to export the key currently held on the mobile app to an install of core

not the other way round as you suggest.

yes of course, as the built-in documentation states

Without explicit arguments, the utility will load the active key-chain. (…) When providing a key-chain (packed or named), the utility first checks if it’s a packed key-chain.

According to this all you need to do is to execute:
keychain [SECRET] where SECRET is the value taken from the mobile app (first row in Settings view).

1 Like