Keystore
cyber cyb

Keystore management

Key types

Key types can be conditionally divided into two groups: agents and validators.

Agents keys are used for linking content, sending liquid tokens, delegating, redelegating, and undelegating tokens to validators. Also, withdrawing rewards, voting and creating multisig accounts.

  • cyber a.k.a. address. Cyberdcli application key.

    • Derived from account mnemonic phrase, generated by cyberdcli keys add
    • e.g. cyber15h6vd5f0wqps26zjlwrc6chah08ryu4hzzdwhc

  • cyberpub the public key of an account address. It is used for generating multisig addresses.

    • Derived from account mnemonic phrase, generated by cyberdcli keys add
    • e.g. cyberpub1zcjduc3q7fu03jnlu2xpl75s2nkt7krm6grh4cc5aqth73v0zwmea25wj2hsqhlqzm

All agents keypairs are stored locally in the PATH_TO_CYBERD/cli/keys folder. You can backup this folder to easily migrate between testnets or machines.

Validators are actors on the network committing new blocks by submitting their votes. This refers to the node itself, not a single person or a single account. Therefore, the public key here is referring to the nodes public key, not the public key of the agent address.

  • cybervaloper validator application-level address. It is associated with a public key cybervalconspub. This is the address used to identify your validator publicly. The private key associated with this address is used to delegate, unbond, claim rewards, and participate in governance. Generated by cyberdcli on the application level. Application keys are associated with a public key prefixed by cyberpub and an address prefixed by cyberd network. Both are derived from account keys generated by cyberdcli keys add.

    • e.g. cybervaloper1carzvgq3e6y3z5kz5y6gxp3wpy3qdrv928vyah

  • cybervalconspub the public key of node/validator address. The private key associated with this Tendermint PubKey is used to sign prevotes and precommits.

    • Generated when the node is created
    • Get this value with cyberdcli tendermint show-validator
    • e.g. cybervalconspub1zcjduepq0ms2738680y72v44tfyqm3c9ppduku8fs6sr73fx7m666sjztznqzp2emf

Note: A validator’s operator key is directly tied to an application key, but uses reserved prefixes solely for this purpose: cybervaloper and cybersvaloperpub.

A nodes keypair is stored in node_key.json and priv_validator_key.json at PATH_TO_CYBERD/daemon/config folder. You can delete them and restart cyberd if you want to change this keypair. The new pair will be created automatically. Or you can backup it up and insert in the same folder during a new testnet if you want the same nodes pubkey.

Generate keys

You’ll need an account private and public key pair (a.k.a. sk, pk respectively) to be able to receive funds, send txs, bond tx, etc.

To generate a new secp256k1 key:

cyberdcli keys add

Next, you will have to create a passphrase to protect the key on disk. The output of the above the command will contain a seed phrase. It is recommended to save the seed phrase in a safe place so that in case you forget the password, you could eventually regenerate the key from the seed phrase with the following command:

cyberdcli keys add  --recover

Also, you can import your ETH account to cyberdcli:

cyberdcli keys add import_private

by using the ETH private key

… and Cosmos account by seed phrase:

cyberdcli keys add  --recover

cyberdcli provides compatibility of Cosmos and ETH public keys with Cyber addresses.

You can check your application account details by account name:

cyberdcli keys show

You can see all of your available keys by typing:

cyberdcli keys list

View the validator pubkey for your node by typing:

cyberdcli tendermint show-validator
Note that this is the Tendermint signing key, not the operator key you will use in delegation transactions.
::: danger Warning We strongly recommend NOT using the same passphrase for multiple keys. The cyberd team and/or the cyber~Congress team will not be responsible for the loss of funds. :::

Important note: Starting with v.38 cosmos-SDK uses os-native keyring to store all your keys. We’ve noticed that in certain cases this does not work well by default (for example if you don’t have any GUI installed on your machine). If during the execution of the cyberdcli keys add command you get this type of error:

panic: No such interface 'org.freedesktop.DBus.Properties' on object at path /

goroutine 1 [running]:
github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeInfo(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk/crypto/keys/keyring.go:479 +0x38c
github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.writeLocalKey(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x147a6c0, 0xc000f1c780, ...)
    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk/crypto/keys/keyring.go:465 +0x189
github.com/cosmos/cosmos-sdk/crypto/keys.baseKeybase.CreateAccount(0x1307a18, 0x1307a10, 0xc000b37160, 0x1, 0x1, 0xc000b37170, 0x1, 0x1, 0x146aa00, 0xc000b15630, ...)
    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk/crypto/keys/keybase_base.go:171 +0x192
github.com/cosmos/cosmos-sdk/crypto/keys.keyringKeybase.CreateAccount(...)
    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk/crypto/keys/keyring.go:107
github.com/cosmos/cosmos-sdk/client/keys.RunAddCmd(0xc000f0b400, 0xc000f125f0, 0x1, 0x1, 0x148dcc0, 0xc000aca550, 0xc000ea75c0, 0xc000ae1c08, 0x5e93b7)
    /root/go/pkg/mod/github.com/cosmos/cosmos-sdk/client/keys/add.go:273 +0xa8b
... etc

You will have to use another keyring backend to keep your keys. Here are 2 options: store the files within the cli folder or a pass manager.

Setting the keyring backend to a local file:

Execute:

cyberdcli config keyring-backend file

As a result you migth see the following: configuration saved to /root/.cybercli/config/config.toml

Execute:

cyberdcli config --get keyring-backend

The result should be the following:

user:~# cyberdcli config --get keyring-backend
file

This means that you’ve set your keyring-backend to a local file. Note, in this case, all the keys in your keyring will be encrypted using the same password. If you would like to set up a unique password for each key, you should set a unique --home folder for each key. To do that, just use --home=// with setup keyring backend and at all interactions with keys when using cyberdcli:

cyberdcli config keyring-backend file --home=//
cyberdcli keys add  --home=//
cyberdcli keys list --home=//

Set keyring backend to pass manager:

Pass utility uses a GPG key to encrypt your keys (but again, it uses the same GPG for all the keys). To install and generate your GPG key you should follow this guide or this very detailed guide. When you’ll get your pass set, configure cyberdcli to use it as a keyring backend:

cyberdcli config keyring-backend pass

And verify that all set as planned:

cyberdcli config --get keyring-backend
pass

Generate Multisig Public Keys

You can generate and print a multisig public key by typing:

cyberdcli keys add --multisig=name1,name2,name3[...] --multisig-threshold=K new_key_name

K is the minimum number of private keys that must sign the transactions that carry the address of the public key as signer.

The --multisig flag must contain the name of the public keys that will be combined into a public key that will be generated and stored as new_key_name in the local database. All names supplied through --multisig must already exist in the local database. Unless the flag --nosort is set, the order in which the keys are supplied on the command line does not matter, i.e. the following commands generate two identical keys:

cyberdcli keys add --multisig=foo,bar,baz --multisig-threshold=2 multisig_address
cyberdcli keys add --multisig=baz,foo,bar --multisig-threshold=2 multisig_address

Multisig addresses can also be generated on-the-fly and printed by using this command:

cyberdcli keys show --multisig-threshold K name1 name2 name3 [...]

For more information regarding how to generate, sign and broadcast transactions with a multi-signature account see Multisig Guide.