In order to create a keypair for Mainnet or to fully participate in a Mina test network, the first step is to generate a Keypair, which consists of a Public Key and a Private Key. Currently there are two supported tools for generating keypairs mina-generate-keypair and ledger-app-mina. We also have a tool for validating that your private key is created properly.
Note that you may want to generate more than one keypair. For example, if you'd like to run a block producer most securely, you'll want a hot wallet / cold wallet block production setup.
Methods
mina-generate-keypair
We've created a simple command-line utility called mina-generate-keypair. This is the simplest method and instructions can be found below.
Ledger Hardware Wallet
You can use your Ledger Nano S hardware wallet to securely store your Mina private keys. We are in the process of an independent security audit which currently has found no vulnerabilities, and development is nearly completed. Please see our ledger-app-mina documentation to get started with this tool.
Client SDK
We've also created a client SDK that is able to generate key pairs and sign transactions. Please note that this method is unadvised and should only be used by experienced security professionals. Please use our `mina-generate-keypair tool instead for creating key pairs. See our client SDK documentation for more information.
WARNING
Never give out your private key and make sure they are stored safely. If you lose your private key or if a malicious actor gains access to your private key, you will lose access to your account and will lose your account funds. Always give out your public keys instead. Mina will never ask you for your private keys.
Using mina-generate-keypair
To simplify the process of creating a keypair, we've created a simple command-line utility called mina-generate-keypair. The mina-generate-keypair tool has easy to use functionality to create your own Keypair to start participating in the Mina network. Please see below to see how to install and use on your local system.
Installation
We support several different operating systems for the mina-generate-keypair tool. Follow the instructions below to install the tool onto your system.
macOS
If you are using macOS please install Docker and follow the docker based instructions below.
Ubuntu 18.04 / Debian 9
After adding the Mina repo you can simply run the following command.
Check that keygen tool installed correctly by running mina-generate-keypair -version. The output should read Commit feee67cc2836bf12e792510a2440f28a0275740e on branch master .
Windows / Other Platforms
Install Docker and follow the Docker-based instructions in step 3b. below.
Usage
Creating a keypair is simple and is accomplished in a few short steps.
First make sure you have a folder on your system where you can store the key files. We recommend using the ~/keys folder.
mkdir ~/keys
Next, ensure the permissions are set properly this folder, this prevents unwanted processes from accessing these files.
chmod 700 ~/keys
Generate a key using either the instructions in Step 3a on Debian/Ubuntu, or Step 3b in Docker
WARNING
Make sure to set a new and secure password for the following commands. Mina will never ask you for this password, and you should not share it with anyone.
3a. In Ubuntu/Debian: Generate your keys using the mina-generate-keypair command. When prompted, type in the password you intend to use to secure this key. If is set, the tool will use the password from the CODA_PRIVKEY_PASS environment variable instead of prompting you. Do NOT forget this password.
3b. In Docker on Windows/MacOS/Linux: Generate your keys using the minaprotocol/generate-keypair docker image. When prompted, type in the password you intend to use to secure this key. Do NOT forget this password.
cd ~
docker run --interactive --tty --rm --volume $(pwd)/keys:/keys minaprotocol/mina-generate-keypair:1.2.2-feee67c --privkey-path /keys/my-wallet
This will create two files on your system, ~/keys/my-wallet which contains the encrypted private key and ~/keys/my-wallet.pub which contains the public key in plain text. Please store the private key file and password you used in a secure place, such as a password manager.
WARNING
Never give out your private key and make sure they are stored safely. If you lose your private key or if a malicious actor gains access to your private key, you will lose access to your account and will lose your account funds. Always give out your public keys instead. Mina will never ask you for your private keys.
Finally, ensure the permissions are set properly for the private key file, this prevents unwanted processes from accessing it.
chmod 600~/keys/my-wallet
Validate your private key
Now that you've created your key -- you'll want to validate that it works. It's sufficient to verify that you can sign a transaction. You can verify this using the mina-validate-keypair tool.
If you are using Docker run the following command:
docker run --interactive --tty --rm --volume $(pwd)/keys:/keys minaprotocol/mina-generate-keypair:1.2.2-feee67c --privkey-path /keys/my-wallet
Next steps
Now that we have created our keypair, we can finally connect to the network or share your public key.
Connect to the Network In this section, we'll connect to the Mainnet network and send our first transaction. Let's first start up the node so that we can begin issuing commands.
Update your software The first step in connecting to Mainnet is installing the latest daemon version. Follow the instructions for your operating system below.
Ubuntu 18.04 / Debian 9 Follow along below to install the latest Stable Mina Release 1.2.2 or visit the Github Releases Page to discover and install pre-release (Beta) builds.
You can set up the new debian stretch stable respository and install the latest version as follows:
echo "deb [trusted=yes] http://packages.o1test.net stretch stable" | sudo tee /etc/apt/sources.list.d/mina.list sudo apt-get update sudo apt-get install -y curl unzip mina-mainnet=1.2.2-feee67c Check that daemon installed correctly by running mina version. The output should read Commit feee67cc2836bf12e792510a2440f28a0275740e on branch master.
Start up a node Since this technology is still relatively new, there are a few rare situations where your node can run into some issues. We don't want for your nodes to break and you not realize! So we've made some officially supported auto-restart flows for you. We'll be iterating on these in future releases.
However, first we'll want to make sure everything works by running it manually before starting with the auto-restart flows.
Note: If you are using the Hetzner hosting provider, we are currently experiencing an issue where Hetzner believes our software is being malicious. See the Networking section of the troubleshooting page to learn how to mitigate this before starting a node.
Run the following command to start up a Mina node instance and connect to the live network:
mina daemon --peer-list-url https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt If you have a key with stake and would like to produce blocks, also provide --block-producer-key ~/keys/my-wallet, replacing ~/keys/my-wallet with the path to your private key if not the default.
The --peer-list argument specified above refer to the seed peer address - this is the initial peer we will connect to on the network. Since Mina is a peer-to-peer protocol, there is no single centralized server we rely on.
See here for common issues when first running a node.
You're not done yet! Now that you've confirmed things are okay by running the standalone process, it is important we start Mina in a manner that will auto-restart itself when it dies.
First kill the existing mina daemon process with Ctrl-C, and then keep reading:
Ubuntu 18.04 / Debian 9 To produce blocks or otherwise customize the configuration for the mina daemon, create a file ~/.mina-env containing the following:
CODA_PRIVKEY_PASS="My_V3ry_S3cure_Password" LOG_LEVEL=Info FILE_LOG_LEVEL=Debug EXTRA_FLAGS=" --block-producer-key " Ensure to replace with the full path to your block producer private key, for example, /home/ubuntu/keys/my-wallet. If you do not intend to produce blocks then you can keep ~/.mina-env empty for now. To change how mina is configured, simply specify flags to the mina daemon process with space-separated arguments between the quotes in EXTRA_FLAGS="". The mina systemd service no longer expects a peers.txt file, it just uses the PEERS_LIST_URL variable to determine where to fetch initial peers from, and the PEERS_LIST_URL for the mainnet package defaults to https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt . Once your .mina-env is ready, run the following commands to start up a Mina node instance and connect to the live network: systemctl --user daemon-reload systemctl --user start mina systemctl --user enable mina sudo loginctl enable-linger These commands will allow the node to continue running after you logout, and restart automatically when the machine reboots. By default, the node connects to the network using the default external-port of 8302. This can be changed using the -external-port flag, just add that to EXTRA_FLAGS. You can also look into the mina process itself that's running in the background and auto-restarting. This command will let you know if mina had any trouble getting started. systemctl --user status mina You can stop mina gracefully, and stop automatically-restarting the service: systemctl --user stop mina Manually Restart it: systemctl --user restart mina And look at logs: journalctl --user -u mina -n 1000 -f In some cases in order to view logs you need to run the following command instead: journalctl --user-unit mina -n 1000 -f That command will show you the last 1000 lines and follow from there. Docker When running your daemon using Docker, first ensure that your private key has the correct permissions. cd ~ chmod 700 ~/keys chmod 600 ~/keys/my-wallet mkdir ~/.mina-config Now simply run the image with your keys and ~/.mina-config mounted: Send a payment with Mina In this section, we'll give a brief overview on how to send a transaction with the Mina client and how to get started with interacting with the blockchain. Using an offline signed-transaction If you want to send a transaction without running a node yourself, but by delegating to someone else running a node, keep following along here. If you wish to send the transaction directly with a running node, skip to using a connected node. Using a Ledger device To generate a signed transaction offline if your private key is on a Ledger device, see Ledger Offline Mode. Using a keypair generated with the generate-keypair tool A better tool is coming soon:
In order to create a keypair for Mainnet or to fully participate in a Mina test network, the first step is to generate a Keypair, which consists of a Public Key and a Private Key. Currently there are two supported tools for generating keypairs mina-generate-keypair and ledger-app-mina. We also have a tool for validating that your private key is created properly.
Note that you may want to generate more than one keypair. For example, if you'd like to run a block producer most securely, you'll want a hot wallet / cold wallet block production setup.
Methods
mina-generate-keypair
We've created a simple command-line utility called mina-generate-keypair. This is the simplest method and instructions can be found below.
Ledger Hardware Wallet
You can use your Ledger Nano S hardware wallet to securely store your Mina private keys. We are in the process of an independent security audit which currently has found no vulnerabilities, and development is nearly completed. Please see our ledger-app-mina documentation to get started with this tool.
Client SDK
We've also created a client SDK that is able to generate key pairs and sign transactions. Please note that this method is unadvised and should only be used by experienced security professionals. Please use our `mina-generate-keypair tool instead for creating key pairs. See our client SDK documentation for more information.
WARNING
Never give out your private key and make sure they are stored safely. If you lose your private key or if a malicious actor gains access to your private key, you will lose access to your account and will lose your account funds. Always give out your public keys instead. Mina will never ask you for your private keys.
Using mina-generate-keypair
To simplify the process of creating a keypair, we've created a simple command-line utility called mina-generate-keypair. The mina-generate-keypair tool has easy to use functionality to create your own Keypair to start participating in the Mina network. Please see below to see how to install and use on your local system.
Installation
We support several different operating systems for the mina-generate-keypair tool. Follow the instructions below to install the tool onto your system.
macOS
If you are using macOS please install Docker and follow the docker based instructions below.
Ubuntu 18.04 / Debian 9
After adding the Mina repo you can simply run the following command.
Check that keygen tool installed correctly by running mina-generate-keypair -version. The output should read Commit feee67cc2836bf12e792510a2440f28a0275740e on branch master .
Windows / Other Platforms
Install Docker and follow the Docker-based instructions in step 3b. below.
Usage
Creating a keypair is simple and is accomplished in a few short steps.
First make sure you have a folder on your system where you can store the key files. We recommend using the ~/keys folder.
mkdir ~/keys
Next, ensure the permissions are set properly this folder, this prevents unwanted processes from accessing these files.
chmod 700 ~/keys
Generate a key using either the instructions in Step 3a on Debian/Ubuntu, or Step 3b in Docker
WARNING
Make sure to set a new and secure password for the following commands. Mina will never ask you for this password, and you should not share it with anyone.
3a. In Ubuntu/Debian: Generate your keys using the mina-generate-keypair command. When prompted, type in the password you intend to use to secure this key. If is set, the tool will use the password from the CODA_PRIVKEY_PASS environment variable instead of prompting you. Do NOT forget this password.
3b. In Docker on Windows/MacOS/Linux: Generate your keys using the minaprotocol/generate-keypair docker image. When prompted, type in the password you intend to use to secure this key. Do NOT forget this password.
cd ~
docker run --interactive --tty --rm --volume $(pwd)/keys:/keys minaprotocol/mina-generate-keypair:1.2.2-feee67c --privkey-path /keys/my-wallet
This will create two files on your system, ~/keys/my-wallet which contains the encrypted private key and ~/keys/my-wallet.pub which contains the public key in plain text. Please store the private key file and password you used in a secure place, such as a password manager.
WARNING
Never give out your private key and make sure they are stored safely. If you lose your private key or if a malicious actor gains access to your private key, you will lose access to your account and will lose your account funds. Always give out your public keys instead. Mina will never ask you for your private keys.
Finally, ensure the permissions are set properly for the private key file, this prevents unwanted processes from accessing it.
chmod 600~/keys/my-wallet
Validate your private key
Now that you've created your key -- you'll want to validate that it works. It's sufficient to verify that you can sign a transaction. You can verify this using the mina-validate-keypair tool.
If you are using Docker run the following command:
docker run --interactive --tty --rm --volume $(pwd)/keys:/keys minaprotocol/mina-generate-keypair:1.2.2-feee67c --privkey-path /keys/my-wallet
Next steps
Now that we have created our keypair, we can finally connect to the network or share your public key.
Connect to the Network In this section, we'll connect to the Mainnet network and send our first transaction. Let's first start up the node so that we can begin issuing commands.
Update your software The first step in connecting to Mainnet is installing the latest daemon version. Follow the instructions for your operating system below.
Ubuntu 18.04 / Debian 9 Follow along below to install the latest Stable Mina Release 1.2.2 or visit the Github Releases Page to discover and install pre-release (Beta) builds.
You can set up the new debian stretch stable respository and install the latest version as follows:
echo "deb [trusted=yes] http://packages.o1test.net stretch stable" | sudo tee /etc/apt/sources.list.d/mina.list sudo apt-get update sudo apt-get install -y curl unzip mina-mainnet=1.2.2-feee67c Check that daemon installed correctly by running mina version. The output should read Commit feee67cc2836bf12e792510a2440f28a0275740e on branch master.
Start up a node Since this technology is still relatively new, there are a few rare situations where your node can run into some issues. We don't want for your nodes to break and you not realize! So we've made some officially supported auto-restart flows for you. We'll be iterating on these in future releases.
However, first we'll want to make sure everything works by running it manually before starting with the auto-restart flows.
Note: If you are using the Hetzner hosting provider, we are currently experiencing an issue where Hetzner believes our software is being malicious. See the Networking section of the troubleshooting page to learn how to mitigate this before starting a node.
Run the following command to start up a Mina node instance and connect to the live network:
mina daemon --peer-list-url https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt If you have a key with stake and would like to produce blocks, also provide --block-producer-key ~/keys/my-wallet, replacing ~/keys/my-wallet with the path to your private key if not the default.
The --peer-list argument specified above refer to the seed peer address - this is the initial peer we will connect to on the network. Since Mina is a peer-to-peer protocol, there is no single centralized server we rely on.
See here for common issues when first running a node.
You're not done yet! Now that you've confirmed things are okay by running the standalone process, it is important we start Mina in a manner that will auto-restart itself when it dies.
First kill the existing mina daemon process with Ctrl-C, and then keep reading:
Ubuntu 18.04 / Debian 9 To produce blocks or otherwise customize the configuration for the mina daemon, create a file ~/.mina-env containing the following:
CODA_PRIVKEY_PASS="My_V3ry_S3cure_Password" LOG_LEVEL=Info FILE_LOG_LEVEL=Debug EXTRA_FLAGS=" --block-producer-key " Ensure to replace with the full path to your block producer private key, for example, /home/ubuntu/keys/my-wallet. If you do not intend to produce blocks then you can keep ~/.mina-env empty for now. To change how mina is configured, simply specify flags to the mina daemon process with space-separated arguments between the quotes in EXTRA_FLAGS="". The mina systemd service no longer expects a peers.txt file, it just uses the PEERS_LIST_URL variable to determine where to fetch initial peers from, and the PEERS_LIST_URL for the mainnet package defaults to https://storage.googleapis.com/mina-seed-lists/mainnet_seeds.txt . Once your .mina-env is ready, run the following commands to start up a Mina node instance and connect to the live network: systemctl --user daemon-reload systemctl --user start mina systemctl --user enable mina sudo loginctl enable-linger These commands will allow the node to continue running after you logout, and restart automatically when the machine reboots. By default, the node connects to the network using the default external-port of 8302. This can be changed using the -external-port flag, just add that to EXTRA_FLAGS. You can also look into the mina process itself that's running in the background and auto-restarting. This command will let you know if mina had any trouble getting started. systemctl --user status mina You can stop mina gracefully, and stop automatically-restarting the service: systemctl --user stop mina Manually Restart it: systemctl --user restart mina And look at logs: journalctl --user -u mina -n 1000 -f In some cases in order to view logs you need to run the following command instead: journalctl --user-unit mina -n 1000 -f That command will show you the last 1000 lines and follow from there. Docker When running your daemon using Docker, first ensure that your private key has the correct permissions. cd ~ chmod 700 ~/keys chmod 600 ~/keys/my-wallet mkdir ~/.mina-config Now simply run the image with your keys and ~/.mina-config mounted: Send a payment with Mina In this section, we'll give a brief overview on how to send a transaction with the Mina client and how to get started with interacting with the blockchain. Using an offline signed-transaction If you want to send a transaction without running a node yourself, but by delegating to someone else running a node, keep following along here. If you wish to send the transaction directly with a running node, skip to using a connected node. Using a Ledger device To generate a signed transaction offline if your private key is on a Ledger device, see Ledger Offline Mode. Using a keypair generated with the generate-keypair tool A better tool is coming soon:
provided in a comment on that issue. Using a keypair generated with the offline client-sdk To generate a signed transaction using the client-sdk, log the signed payment created as shown on the
Using a connected node We are assuming in the rest of section that you have the Mina client installed on your system, if you do not have Mina installed please see the Getting Started. Import your account Once our node is synced, we'll need to import our public/private keypair so that we can sign transactions and generate an address to receive payments. For security reasons, we'll want to put the keys under a directory that is harder for attackers to access. Run the following command to import your previously generated keypair file: mina accounts import --privkey-path ~/keys/my-wallet
You will be prompted for the password you entered when the account was created. WARNING The public key can be shared freely with anyone, but be very careful with your private key file. Never share this private key with anyone, as it is the equivalent of a password for your funds. The response from this command will look like this: 😄 Imported account!
Public key: B62qjaA4N9843FKM5FZk1HmeuDiojG42cbCDyZeUDQVjycULte9PFkC
Additionally you can use the
mina accounts create
command to generate new accounts to send and receive transactions. Since the public key is quite long and difficult to remember, let's save it as an environment variable. Use the following command but replace
<YOUR-PUBLIC-KEY>
with the public key output from the previous command: export MINA_PUBLIC_KEY=<YOUR-PUBLIC-KEY>
Now we can access this everywhere as
$MINA_PUBLIC_KEY
-- check if it saved properly by trying
echo $MINA_PUBLIC_KEY
. Note that these environment variables will only be saved for the current shell session, so if you want to save them for future use, you can add them to
~/.profile
or
~/.bash_profile
. NOTE If you are running the node on a cloud virtual machine, make sure to export and save the key file. You can export the key with: mina accounts export --public-key <PUBLIC-KEY> --privkey-path <EXPORT-PATH>
Then save it to your local machine, maybe using
: scp <EXPORT-PATH> <LOCAL-DESTINATION>
Later, when starting up a new VM, you can upload the key and then import it: mina accounts import --privkey-path <PRIVATE-KEY-FILE>
If you ever forget what keypairs you've already created, you can see them all with: mina accounts list
Check account balance We can check the balance of all our accounts using this command: mina accounts list
You might see
Balance: 0 mina
for your account. Depending on the traffic in the network, it may take a few blocks before your transaction goes through. NOTE Tip: You can run
mina client status
to see the current block height updating. Make a payment Finally, we get to the good stuff–sending our first transaction! Before you send a payment, you'll need to unlock your account: mina accounts unlock --public-key $MINA_PUBLIC_KEY
For testing purposes, we will specify your public key as the receiver and sender. This just means that we are sending a transaction to ourselves, you can see your public key by issuing the following command: echo $MINA_PUBLIC_KEY
WARNING If the receiving account has not received any transactions, there will be an additional Account Creation Fee of
1 MINA
that will be deducted from the transaction amount. Let's send some of our Mina to ourselves to see what a payment looks like: mina client send-payment \
--amount 1.5 \
--receiver $MINA_PUBLIC_KEY \
--fee 0.1 \
--sender $MINA_PUBLIC_KEY
If you're wondering what we passed in to the commands above: For
amount
, we're sending a test value of
1.5
mina which is enough to cover the Account Creation Fee The
receiver
is the public key of the account receiving the transaction, eg.
B62qjaA4N9843FKM5FZk...
For
fee
, let's use 0.1 mina The
sender
is the public key of the account sending the transaction, eg.
B62qjaA4N9843FKM5FZk...
If this command is formatted properly, we should get a response that looks like the following: Dispatched payment with ID 3XCgvAHLAqz9VVbU7an7f2L5ffJtZoFega7jZpVJrPCYA4j5HEmUAx51BCeMc232eBWVz6q9t62Kp2cNvQZoNCSGqJ1rrJpXFqMN6NQe7x987sAC2Sd6wu9Vbs9xSr8g1AkjJoB65v3suPsaCcvvCjyUvUs8c3eVRucH4doa2onGj41pjxT53y5ZkmGaPmPnpWzdJt4YJBnDRW1GcJeyqj61GKWcvvrV6KcGD25VEeHQBfhGppZc7ewVwi3vcUQR7QFFs15bMwA4oZDEfzSbnr1ECoiZGy61m5LX7afwFaviyUwjphtrzoPbQ2QAZ2w2ypnVUrcJ9oUT4y4dvDJ5vkUDazRdGxjAA6Cz86bJqqgfMHdMFqpkmLxCdLbj2Nq3Ar2VpPVvfn2kdKoxwmAGqWCiVhqYbTvHkyZSc4n3siGTEpTGAK9usPnBnqLi53Z2bPPaJ3PuZTMgmdZYrRv4UPxztRtmyBz2HdQSnH8vbxurLkyxK6yEwS23JSZWToccM83sx2hAAABNynBVuxagL8aNZF99k3LKX6E581uSVSw5DAJ2S198DvZHXD53QvjcDGpvB9jYUpofkk1aPvtW7QZkcofBYruePM7kCHjKvbDXSw2CV5brHVv5ZBV9DuUcuFHfcYAA2TVuDtFeNLBjxDumiBASgaLvcdzGiFvSqqnzmS9MBXxYybQcmmz1WuKZHjgqph99XVEapwTsYfZGi1T8ApahcWc5EX9
Receipt chain hash is now A3gpLyBJGvcpMXny2DsHjvE5GaNFn2bbpLLQqTCHuY3Nd7sqy8vDbM6qHTwHt8tcfqqBkd36LuV4CC6hVH6YsmRqRp4Lzx77WnN9gnRX7ceeXdCQUVB7B2uMo3oCYxfdpU5Q2f2KzJQ46
You may not see the
Receipt chain hash
on the first transaction from the account, but in following transactions, this will show you the head of the receipt chain hash list. Staking and Snarking Once you feel comfortable with the basics of creating an address, and sending & receiving mina, we can move on to the truly unique parts of the Mina network like participating in consensus and helping compress the blockchain. Advanced Sending Many Transactions Sometimes you may wish to send many transactions: for example, to payout rewards to those delegating to you if you're running a staking pool. All information here is relevant as of the 1.2.2 build: Rate limiting Currently, nodes on the network will rate limit receiving messages from a given node. As of the 1.2.2 build, your node will also follow this rate limit when sending transactions. Specifically, the limit is currently set at 10 transactions every 15 seconds computed over a 5 minute window. If you attempt to send transactions faster than this rate, your node will queue them up and flush them as older transactions expire from the window upon which the rate limit is computed. You do not need to throttle sending these transactions yourself. Note that older releases of the mina daemon do not perform this rate limiting; if you are running an older version, you should manually limit the number of transactions. Due to overheads from rebroadcasting transactions, we do not recommend sending more than 50 transactions every 5 minutes if you need to manually rate limit. My node crashed or disconnected before I could finish sending transactions The Mina daemon does
not
currently persist the transaction pool. This means that the transactions that your node will be unaware of any transactions that you've sent so far if your node crashes in the middle of this process. As of the 1.2.2 build, you can resend all transactions (exactly in the same manner as before) and they will be rebroadcasted on the network. If you believe you were temporarily disconnected from the network, but your node stayed online (i.e. the gossip network may have missed one or more of your transactions), as of the 1.2.2 build, you can resend any of the transactions locally and they will be broadcasted again to the network even if your node thinks they've already been shared. Cancelling a transaction and setting a new fee To cancel a transaction, you'll need to have all the transactions that haven't been committed to the chain yet before in your local transaction mempool. This means if your node crashed (see above) you'll need to resend those earlier transactions. Finally, to cancel a transaction, all you need to do is send a transaction with the same nonce of the one you want to cancel with a larger fee. There is no minimum increment, it just needs to be slightly larger (and large enough such that a block producer will choose your transaction). Get Updates Mina is growing fast! Subscribe to stay updated
RE Staking & Snarking Let's turn our attention to the other ways we can interact with the Mina network - namely, participating in consensus, and helping compress data by generating zk-SNARKs. By operating a node that helps secure the network, you can receive mina for your efforts. Participating in Consensus The Mina network is secured by Proof-of-Stake consensus. With this model of consensus, you don't need to have complex equipment like in Bitcoin mining. By simply having mina in our wallet, we can choose to either stake it ourselves, or delegate it to another node. Let's first see how to stake mina ourselves: WARNING To properly remain synced to the network and participate in consensus, it is important that your server is running some form of a
, which is relatively easy to setup and comes already installed as a default service on many popular linux distros. Staking mina We can try out staking with our mina by issuing the following command: mina client set-staking --public-key $MINA_PUBLIC_KEY
Alternatively, you can restart the daemon with the
-block-producer-pubkey
flag: mina daemon \
-peer-list ~/peers.txt \
-block-producer-pubkey $MINA_PUBLIC_KEY
We can always check which accounts we're currently staking with, by using the
mina client status
command: mina client status
Mina daemon status
-----------------------------------
Global number of accounts: 372
Block height: 20
Max observed block length: 20
Local uptime: 1m48s
Ledger Merkle root: ...
Protocol state hash: ...
Staged Hash: ...
Git SHA-1: ...
Configuration directory: ...
Peers: 5 (...)
User_commands sent: 0
SNARK worker: None
SNARK work fee: 1
Sync status: Synced
Block producers running: 1 (...)
Best tip consensus time: epoch=0, slot=133
Next proposal: None this epoch… checking at in 5.284h
Consensus time now: epoch=0, slot=134
Consensus mechanism: proof_of_stake
Consensus configuration: ...
Addresses and ports: ...
Libp2p PeerID: ...
The
Block producers running
field in the response above returns the number of accounts currently staking, with the associated key. WARNING Keep in mind that if you are staking independently with funds in a account, you'll need to remain connected to the network at all times to successfully produce blocks. If you need to go offline frequently, it may be better to delegate your stake. If you'd like to send your coinbase to an account other than the one that is staking, you can use the
-coinbase-receiver
flag when you start your daemon. You can even point the coinbase at a cold wallet! Delegating mina Delegating mina is an alternative option to staking it directly, with the benefit of not having to maintain a node that is always connected to the network. First make sure you've unlocked your account: mina account unlock --public-key $MINA_PUBLIC_KEY
And then run this command to delegate your stake: mina client delegate-stake \
--receiver <DELEGATE-PUBLIC-KEY> \
--sender $MINA_PUBLIC_KEY \
--fee 0.1
The fields in this command: The
receiver
flag is the public key of the receiver of your stake delegation
sender
is the public key of the account from which you want to delegate
fee
is the cost to send your transaction. It is paid to the network’s block producers. Note there is no
amount
parameter. Your full Mina balance will be delegated automatically. You'll notice that this command looks suspiciously like a payment transaction. That's because a stake delegation is also a transaction! This is why we have to pay a small transaction fee in order to change this setting. Delegating your stake might be useful if you're interested in: Running your own staking node that uses funds from a "cold wallet" Delegating to a "staking pool" which will provide token payouts periodically Or if you don't have enough tokens to make managing a block producer full-time worthwhile NOTE There is a latency period of a 2-4 weeks before your new stake delegation comes into effect Compressing data in the Mina network The Mina protocol is unique in that it doesn't require nodes to maintain the full history of the blockchain like other cryptocurrency protocols. By recursively using cryptographic proofs, the Mina protocol effectively compresses the blockchain to constant size. We call this compression, because it reduces terabytes of data to a few kilobytes. However, this isn't data encoding or compression in the traditional sense - rather nodes "compress" data in the network by generating cryptographic proofs. Node operators play a crucial role in this process by designating themselves as "snark-workers" that generate zk-SNARKs for transactions that have been added to blocks. You can start a snark-worker using these commands: mina client set-snark-work-fee <FEE>
mina client set-snark-worker --address $MINA_PUBLIC_KEY
Alternatively, you can restart the daemon with these flags: mina daemon \
-peer-list ~/peers.txt \
-run-snark-worker $MINA_PUBLIC_KEY \
-snark-worker-fee <fee>
As a snark worker, you get to share some of the block reward for each block your compressed transactions make it in to. The block producer is responsible for gathering compressed transactions before including them into a block, and will be incentivized by the protocol to reward snark-workers. Snark workers can be fairly compute intensive, so if you need to limit their CPU usage, you can specify the number of threads snark workers use with the
-snark-worker-parallelism
flag. This can be especially useful if you're trying to run a block producer and snark worker on the same machine and having issues producing blocks in time. That about covers the roles and responsibilities as a Mina node operator. Since Mina is a permissionless peer-to-peer network, everything is managed and run in a decentralized manner by nodes all over the world. Similarly, the Mina project is also distributed and permissionless to join. The code is all open source, and there is much work to be done, both technical and non-technical. To learn more about how you can get involved with Mina, please check out the Contributing to Mina section. Using daemon.json to configure your mina daemon By creating a file at
~/.mina-config/daemon.json
, you can configure your mina daemon without needing to provide options on the commandline. This can be useful for running mina as a service as well as just for avoiding repetitive typing! Most of the options that can be passed to
mina daemon
on the commandline can also be provided as options in the config file. See
mina daemon -help
for more documentation of the options. Below is an example of usage of all the usable configuration parameters (in your file, you only need to specify the ones you want to change): {
"daemon": {
"client-port": 1000,
"external-port": 1001,
"rest-port": 1002,
"block-producer-key": "/path/to/privkey-file",
"block-producer-password": "mypassword",
"block-producer-pubkey": "<MY PUBLICKEY>",
"coinbase-receiver": "<MY PUBLICKEY>",
"log-block-creation": false,
"log-received-blocks": false,
"log-snark-work-gossip": false,
"log-txn-pool-gossip": false,
"peers": ["seed-one.o1test.net", "seed-two.o1test.net"],
"run-snark-worker": "<MY PUBLICKEY>",
"snark-worker-fee": 10,
"snark-worker-parallelism": 1,
"work-reassignment-wait": 420000,
"work-selection": "seq"
}
}
CLI Reference The Mina CLI (command-line interface) is the primary way for users to interact with the Mina network. It provides standard client functionality to create accounts, send transactions, and participate in consensus. There are also advanced client and daemon commands for power users. The CLI is installed when you install Mina. WARNING Mina APIs are still under construction, so these commands will likely change. See
mina help
for the most up-to-date version. Mina Accounts $ mina accounts help
Client commands concerning account management
mina accounts SUBCOMMAND
=== subcommands ===
list List all owned accounts
create Create new account
import Import a password protected private key to be tracked by the daemon.
Set CODA_PRIVKEY_PASS environment variable to use non-interactively
(key will be imported using the same password).
export Export a tracked account so that it can be saved or transferred
between machines.
Set CODA_PRIVKEY_PASS environment variable to use non-interactively
(key will be exported using the same password).
unlock Unlock a tracked account
lock Lock a tracked account
help explain a given subcommand (perhaps recursively)
Mina Client $ mina client help
Lightweight client commands
mina client SUBCOMMAND
=== subcommands ===
get-balance Get balance associated with a public key
get-tokens Get all token IDs that a public key has accounts for
send-payment Send payment to an address
delegate-stake Delegate your stake to another public key
create-token Create a new token
create-token-account Create a new account for a token
mint-tokens Mint more of a token owned by the command's sender
cancel-transaction Cancel a transaction -- this submits a replacement
transaction with a fee larger than the cancelled
transaction.
set-staking Start producing blocks
set-snark-worker Set key you wish to snark work with or disable snark
working
set-snark-work-fee Set fee reward for doing transaction snark work
export-logs Export daemon logs to tar archive
export-local-logs Export local logs (no daemon) to tar archive
stop-daemon Stop the daemon
status Get running daemon status
help explain a given subcommand (perhaps recursively)
Mina Daemon $ mina daemon -help
Mina daemon
mina daemon
=== flags ===
[--all-peers-seen-metric true|false] whether to track the set
of all peers ever seen for
the all_peers metric
(default: false)
[--archive-address HOST:PORT/LOCALHOST-PORT] Daemon to archive process
communication. If HOST is
omitted, then localhost is
assumed to be HOST.
(examples: 3086,
154.97.53.97:3086)
[--archive-rocksdb] Stores all the blocks
heard in RocksDB
[--background] Run process on the
background
[--bind-ip IP] IP of network interface to
use for peer connections
[--block-producer-key KEYFILE] Private key file for the
block producer. You cannot
provide both
`block-producer-key` and
`block-producer-pubkey`.
(default: don't produce
blocks)
[--block-producer-password PASSWORD] Password associated with
the block-producer key.
Setting this is equivalent
to setting the
CODA_PRIVKEY_PASS
environment variable. Be
careful when setting it in
the commandline as it will
likely get tracked in your
history. Mainly to be used
from the daemon.json
config file
[--block-producer-pubkey PUBLICKEY] Public key for the
associated private key
that is being tracked by
this daemon. You cannot
provide both
`block-producer-key` and
`block-producer-pubkey`.
(default: don't produce
blocks)
[--client-port PORT] local RPC-server for
clients to interact with
the daemon (default: 8301)
[--coinbase-receiver PUBLICKEY] Address to send coinbase
rewards to (if this node
is producing blocks). If
not provided, coinbase
rewards will be sent to
the producer of a block.
[--config-directory DIR] Configuration directory
[--config-file PATH] Path to a configuration
file (overrides
CODA_CONFIG_FILE, default:
<config_dir>/daemon.json).
Pass multiple times to
override fields from
earlier config files
[--current-protocol-version NN.NN.NN] Current protocol version,
only blocks with the same
version accepted
[--demo-mode] Run the daemon in
demo-mode -- assume we're
"synced" to the network
instantly
[--direct-peer /ip4/IPADDR/tcp/PORT/p2p/PEERID] Peers to always send new
messages to/from. These
peers should also have you
configured as a direct
peer, the relationship is
intended to be symmetric
[--disable-node-status] Disable reporting node
status to other nodes
(default: enabled)
[--discovery-keypair KEYFILE] Keypair (generated from
`mina advanced
generate-libp2p-keypair`)
to use with libp2p
discovery (default:
generate per-run temporary
keypair)
[--enable-flooding true|false] Publish our own
blocks/transactions to
every peer we can find
(default: false)
[--enable-mina-peer-exchange true|false] Help keep the mesh
connected when closing
connections (default:
true)
[--enable-peer-exchange true|false] Help keep the mesh
connected when closing
connections (default:
false)
[--external-ip IP] External IP address for
other nodes to connect to.
You only need to set this
if auto-discovery fails
for some reason.
[--external-port PORT] Port to use for all libp2p
communications (gossip and
RPC) (default: 8302)
[--file-log-level LEVEL] Set log level for the log
file
(Spam|Trace|Debug|Info|Warn|Error|Faulty_peer|Fatal,
default: Trace)
[--gc-stat-interval INTERVAL] in mins for collecting GC
stats for metrics
(Default: 15.000000)
[--generate-genesis-proof true|false] Deprecated. Passing this
flag has no effect
[--genesis-ledger-dir DIR] Directory that contains
the genesis ledger and the
genesis blockchain proof
(default: <config-dir>)
[--insecure-rest-server] Have REST server listen on
all addresses, not just
localhost (this is
INSECURE, make sure your
firewall is configured
correctly!)
[--isolate-network true|false] Only allow connections to
the peers passed on the
command line or configured
through GraphQL. (default:
false)
[--libp2p-metrics-port PORT] libp2p metrics server for
scraping via Prometheus
(default no
libp2p-metrics-server)
[--limited-graphql-port PORT] GraphQL-server for limited
daemon interaction
[--log-block-creation true|false] Log the steps involved in
including transactions and
snark work in a block
(default: true)
[--log-json] Print log output as JSON
(default: plain text)
[--log-level LEVEL] Set log level
(Spam|Trace|Debug|Info|Warn|Error|Faulty_peer|Fatal,
default: Info)
[--log-precomputed-blocks true|false] Include precomputed blocks
in the log (default:
false)
[--log-snark-work-gossip true|false] Log snark-pool diff
received from peers
(default: false)
[--log-txn-pool-gossip true|false] Log transaction-pool diff
received from peers
(default: false)
[--max-connections NN] max number of connections
that this peer will have
to neighbors in the gossip
network. Tuning this
higher will strengthen
your connection to the
network in exchange for
using more RAM (default:
50)
[--metrics-port PORT] metrics server for
scraping via Prometheus
(default no
metrics-server)
[--minimum-block-reward AMOUNT] Minimum reward a block
produced by the node
should have. Empty blocks
are created if the rewards
are lower than the
specified threshold
(default: No threshold,
transactions and coinbase
will be included as long
as the required snark work
is available and can be
paid for)
[--no-super-catchup] Don't use super-catchup
[--open-limited-graphql-port] Have the limited GraphQL
server listen on all
addresses, not just
localhost (this is
INSECURE, make sure your
firewall is configured
correctly!)
[--peer /ip4/IPADDR/tcp/PORT/p2p/PEERID] initial "bootstrap" peers
for discovery
[--peer-list-file /ip4/IPADDR/tcp/PORT/p2p/PEERID] initial "bootstrap" peers
for discovery inside a
file delimited by
new-lines (\n)
[--peer-list-url URL] URL of seed peer list
file. Will be polled
periodically.
[--precomputed-blocks-file PATH] Path to write precomputed
blocks to, for replay or
archiving
[--proof-level] full|check|none
[--proposed-protocol-version NN.NN.NN] Proposed protocol version
to signal other nodes
[--rest-port PORT] local REST-server for
daemon interaction
(default: 3085)
[--run-snark-coordinator PUBLICKEY] Run a SNARK coordinator
with this public key
(ignored if the
run-snark-worker is set)
[--run-snark-worker PUBLICKEY] Run the SNARK worker with
this public key
[--seed] Start the node as a seed
node
[--snark-worker-fee FEE] Amount a worker wants to
get compensated for
generating a snark proof
(default: 100000000)
[--snark-worker-parallelism NUM] Run the SNARK worker using
this many threads.
Equivalent to setting
OMP_NUM_THREADS, but
doesn't affect block
production.
[--stop-time UPTIME] in hours after which the
daemon stops itself (only
if there were no slots won
within an hour after the
stop time) (Default: 24)
[--tracing] Trace into
$config-directory/trace/$pid.trace
[--upload-blocks-to-gcloud true|false] upload blocks to gcloud
storage. Requires the
environment variables
GCLOUD_KEYFILE,
NETWORK_NAME, and
GCLOUD_BLOCK_UPLOAD_BUCKET
[--uptime-submitter-key KEYFILE] Private key file for the
uptime submitter. You
cannot provide both
`uptime-submitter-key` and
`uptime-submitter-pubkey`.
[--uptime-submitter-pubkey PUBLICKEY] Public key of the
submitter to the Mina
delegation program, for
the associated private key
that is being tracked by
this daemon. You cannot
provide both
`uptime-submitter-key` and
`uptime-submitter-pubkey`.
[--uptime-url URL] URL of the uptime service
of the Mina delegation
program
[--validation-queue-size NN] size of the validation
queue in the p2p network
used to buffer messages
(like blocks and
transactions received on
the gossip network) while
validation is pending. If
a transaction, for
example, is invalid, we
don't forward the message
on the gossip net. If this
queue is too small, we
will drop messages without
validating them. If it is
too large, we are
susceptible to DoS attacks
on memory. (default: 150)
[--work-reassignment-wait WAIT-TIME] in ms before a snark-work
is reassigned (default:
420000ms)
[--work-selection seq|rand] Choose work sequentially
(seq) or randomly (rand)
(default: rand)
[--working-dir PATH] path to chdir into before
starting (useful for
background mode, defaults
to cwd, or / if
-background)
[-help] print this help text and
exit
(alias: -?)
Mina Advanced $ mina advanced help
Advanced client commands
mina advanced SUBCOMMAND
=== subcommands ===
add-peers Add peers to the daemon
Addresses take the format
/ip4/IPADDR/tcp/PORT/p2p/PEERID
archive-blocks Archive a block from a file.
If an archive address is given, this process will
communicate with the archive node directly;
otherwise it will communicate through the daemon
over the rest-server
batch-send-payments Send multiple payments from a file
chain-id-inputs Print the inputs that yield the current chain id
client-trustlist Client trustlist management
compile-time-constants Print a JSON map of the compile-time consensus
parameters
compute-receipt-chain-hash Compute the next receipt chain hash from the
previous hash and transaction ID
constraint-system-digests Print MD5 digest of each SNARK constraint
dump-keypair Print out a keypair from a private key file
generate-keypair Generate a new public, private keypair
generate-libp2p-keypair Generate a new libp2p keypair and print out the
peer ID
get-nonce Get the current nonce for an account
get-peers List the peers currently connected to the daemon
get-public-keys Get public keys
get-trust-status Get the trust status associated with an IP address
get-trust-status-all Get trust statuses for all peers known to the
trust system
hash-transaction Compute the hash of a transaction from its
transaction ID
next-available-token The next token ID that has not been allocated.
Token IDs are allocated sequentially, so all lower
token IDs have been allocated
node-status Get node statuses for a set of peers
object-lifetime-statistics Dump internal object lifetime statistics to JSON
pending-snark-work List of snark works in JSON format that are not
available in the pool yet
pooled-user-commands Retrieve all the user commands that are pending
inclusion
reset-trust-status Reset the trust status associated with an IP
address
send-rosetta-transactions Dispatch one or more transactions, provided to
stdin in rosetta format
set-coinbase-receiver Set the coinbase receiver
snark-job-list List of snark jobs in JSON format that are yet to
be included in the blocks
snark-pool-list List of snark works in the snark pool in JSON
format
start-tracing Start async tracing to
$config-directory/trace/$pid.trace
status-clear-hist Clear histograms reported in status
stop-tracing Stop async tracing
time-offset Get the time offset in seconds used by the daemon
to convert real time into blockchain time
validate-keypair Validate a public, private keypair
validate-transaction Validate the signature on one or more
transactions, provided to stdin in rosetta format
verify-receipt Verify a receipt of a sent payment
visualization Visualize data structures special to Mina
vrf Commands for vrf evaluations
wrap-key Wrap a private key into a private key file
help explain a given subcommand (perhaps recursively)
next… docker run --name mina -d -p 8302:8302 --restart=always --mount "type=bind,source=
Run docker logs -f mina to follow the logs, and if it crashes save the log output to a file with docker logs mina > mina-log.txt and post the output to the #mentor-nodes channel or attach the full ~/.mina-config/mina.log to a github issue and link the issue in discord. Run docker exec -it mina mina client status to monitor connectivity to the network, you should quickly find at least 10 peers and watch the block height / max observed block height climb. NOTE If you encounter [Warn] Shutdown before Mina instance was created, not saving a visualization when attempting to run your Docker container, increase the resources that the Docker container is allowed to use. Checking connectivity Now that we've started up a node and are running the Mina daemon, open up another shell and run the following command: mina client status NOTE It may take up to a minute before mina client status connects to the daemon when first starting up. So if you see Error: daemon not running. See mina daemon, just a wait a bit and try again. Most likely we will see a response that include the fields below: ... Peers: Total: 4 (...) ... Sync Status: Bootstrap If you see Sync Status: Bootstrap, this means that the node is bootstrapping and needs to sync with the rest of the network. You may need to be patient here as this step might take some time for the node to get all the data it needs. After a while, your node should connect to more peers and then should move into Sync Status: Catchup, which means we're gathering the most recent blocks and state trying to catch up the the highest block. When sync status reaches Synced and the node is connected to 1 or more peers, we will have successfully connected to the network. We will also see a corresponding daemon log once we've synced: [Info] Mina daemon is now synced. If you the Bootstrap state persists for more than an hour, there may be an issue with your port configuration. Stepping up your game Now that we have a fully synced node, we can learn about some of the more advanced features of the daemon such as Sending a payment and Staking & Delegating. And if you want to earn more tokens, check out the Foundation Delegation Program.
provided in a comment on that issue. Using a keypair generated with the offline client-sdk To generate a signed transaction using the client-sdk, log the signed payment created as shown on the
Using a connected node We are assuming in the rest of section that you have the Mina client installed on your system, if you do not have Mina installed please see the Getting Started. Import your account Once our node is synced, we'll need to import our public/private keypair so that we can sign transactions and generate an address to receive payments. For security reasons, we'll want to put the keys under a directory that is harder for attackers to access. Run the following command to import your previously generated keypair file: mina accounts import --privkey-path ~/keys/my-wallet
You will be prompted for the password you entered when the account was created. WARNING The public key can be shared freely with anyone, but be very careful with your private key file. Never share this private key with anyone, as it is the equivalent of a password for your funds. The response from this command will look like this: 😄 Imported account!
Public key: B62qjaA4N9843FKM5FZk1HmeuDiojG42cbCDyZeUDQVjycULte9PFkC
Additionally you can use the
mina accounts create
command to generate new accounts to send and receive transactions. Since the public key is quite long and difficult to remember, let's save it as an environment variable. Use the following command but replace
<YOUR-PUBLIC-KEY>
with the public key output from the previous command: export MINA_PUBLIC_KEY=<YOUR-PUBLIC-KEY>
Now we can access this everywhere as
$MINA_PUBLIC_KEY
-- check if it saved properly by trying
echo $MINA_PUBLIC_KEY
. Note that these environment variables will only be saved for the current shell session, so if you want to save them for future use, you can add them to
~/.profile
or
~/.bash_profile
. NOTE If you are running the node on a cloud virtual machine, make sure to export and save the key file. You can export the key with: mina accounts export --public-key <PUBLIC-KEY> --privkey-path <EXPORT-PATH>
Then save it to your local machine, maybe using
: scp <EXPORT-PATH> <LOCAL-DESTINATION>
Later, when starting up a new VM, you can upload the key and then import it: mina accounts import --privkey-path <PRIVATE-KEY-FILE>
If you ever forget what keypairs you've already created, you can see them all with: mina accounts list
Check account balance We can check the balance of all our accounts using this command: mina accounts list
You might see
Balance: 0 mina
for your account. Depending on the traffic in the network, it may take a few blocks before your transaction goes through. NOTE Tip: You can run
mina client status
to see the current block height updating. Make a payment Finally, we get to the good stuff–sending our first transaction! Before you send a payment, you'll need to unlock your account: mina accounts unlock --public-key $MINA_PUBLIC_KEY
For testing purposes, we will specify your public key as the receiver and sender. This just means that we are sending a transaction to ourselves, you can see your public key by issuing the following command: echo $MINA_PUBLIC_KEY
WARNING If the receiving account has not received any transactions, there will be an additional Account Creation Fee of
1 MINA
that will be deducted from the transaction amount. Let's send some of our Mina to ourselves to see what a payment looks like: mina client send-payment \
--amount 1.5 \
--receiver $MINA_PUBLIC_KEY \
--fee 0.1 \
--sender $MINA_PUBLIC_KEY
If you're wondering what we passed in to the commands above: For
amount
, we're sending a test value of
1.5
mina which is enough to cover the Account Creation Fee The
receiver
is the public key of the account receiving the transaction, eg.
B62qjaA4N9843FKM5FZk...
For
fee
, let's use 0.1 mina The
sender
is the public key of the account sending the transaction, eg.
B62qjaA4N9843FKM5FZk...
If this command is formatted properly, we should get a response that looks like the following: Dispatched payment with ID 3XCgvAHLAqz9VVbU7an7f2L5ffJtZoFega7jZpVJrPCYA4j5HEmUAx51BCeMc232eBWVz6q9t62Kp2cNvQZoNCSGqJ1rrJpXFqMN6NQe7x987sAC2Sd6wu9Vbs9xSr8g1AkjJoB65v3suPsaCcvvCjyUvUs8c3eVRucH4doa2onGj41pjxT53y5ZkmGaPmPnpWzdJt4YJBnDRW1GcJeyqj61GKWcvvrV6KcGD25VEeHQBfhGppZc7ewVwi3vcUQR7QFFs15bMwA4oZDEfzSbnr1ECoiZGy61m5LX7afwFaviyUwjphtrzoPbQ2QAZ2w2ypnVUrcJ9oUT4y4dvDJ5vkUDazRdGxjAA6Cz86bJqqgfMHdMFqpkmLxCdLbj2Nq3Ar2VpPVvfn2kdKoxwmAGqWCiVhqYbTvHkyZSc4n3siGTEpTGAK9usPnBnqLi53Z2bPPaJ3PuZTMgmdZYrRv4UPxztRtmyBz2HdQSnH8vbxurLkyxK6yEwS23JSZWToccM83sx2hAAABNynBVuxagL8aNZF99k3LKX6E581uSVSw5DAJ2S198DvZHXD53QvjcDGpvB9jYUpofkk1aPvtW7QZkcofBYruePM7kCHjKvbDXSw2CV5brHVv5ZBV9DuUcuFHfcYAA2TVuDtFeNLBjxDumiBASgaLvcdzGiFvSqqnzmS9MBXxYybQcmmz1WuKZHjgqph99XVEapwTsYfZGi1T8ApahcWc5EX9
Receipt chain hash is now A3gpLyBJGvcpMXny2DsHjvE5GaNFn2bbpLLQqTCHuY3Nd7sqy8vDbM6qHTwHt8tcfqqBkd36LuV4CC6hVH6YsmRqRp4Lzx77WnN9gnRX7ceeXdCQUVB7B2uMo3oCYxfdpU5Q2f2KzJQ46
You may not see the
Receipt chain hash
on the first transaction from the account, but in following transactions, this will show you the head of the receipt chain hash list. Staking and Snarking Once you feel comfortable with the basics of creating an address, and sending & receiving mina, we can move on to the truly unique parts of the Mina network like participating in consensus and helping compress the blockchain. Advanced Sending Many Transactions Sometimes you may wish to send many transactions: for example, to payout rewards to those delegating to you if you're running a staking pool. All information here is relevant as of the 1.2.2 build: Rate limiting Currently, nodes on the network will rate limit receiving messages from a given node. As of the 1.2.2 build, your node will also follow this rate limit when sending transactions. Specifically, the limit is currently set at 10 transactions every 15 seconds computed over a 5 minute window. If you attempt to send transactions faster than this rate, your node will queue them up and flush them as older transactions expire from the window upon which the rate limit is computed. You do not need to throttle sending these transactions yourself. Note that older releases of the mina daemon do not perform this rate limiting; if you are running an older version, you should manually limit the number of transactions. Due to overheads from rebroadcasting transactions, we do not recommend sending more than 50 transactions every 5 minutes if you need to manually rate limit. My node crashed or disconnected before I could finish sending transactions The Mina daemon does
not
currently persist the transaction pool. This means that the transactions that your node will be unaware of any transactions that you've sent so far if your node crashes in the middle of this process. As of the 1.2.2 build, you can resend all transactions (exactly in the same manner as before) and they will be rebroadcasted on the network. If you believe you were temporarily disconnected from the network, but your node stayed online (i.e. the gossip network may have missed one or more of your transactions), as of the 1.2.2 build, you can resend any of the transactions locally and they will be broadcasted again to the network even if your node thinks they've already been shared. Cancelling a transaction and setting a new fee To cancel a transaction, you'll need to have all the transactions that haven't been committed to the chain yet before in your local transaction mempool. This means if your node crashed (see above) you'll need to resend those earlier transactions. Finally, to cancel a transaction, all you need to do is send a transaction with the same nonce of the one you want to cancel with a larger fee. There is no minimum increment, it just needs to be slightly larger (and large enough such that a block producer will choose your transaction). Get Updates Mina is growing fast! Subscribe to stay updated
RE Staking & Snarking Let's turn our attention to the other ways we can interact with the Mina network - namely, participating in consensus, and helping compress data by generating zk-SNARKs. By operating a node that helps secure the network, you can receive mina for your efforts. Participating in Consensus The Mina network is secured by Proof-of-Stake consensus. With this model of consensus, you don't need to have complex equipment like in Bitcoin mining. By simply having mina in our wallet, we can choose to either stake it ourselves, or delegate it to another node. Let's first see how to stake mina ourselves: WARNING To properly remain synced to the network and participate in consensus, it is important that your server is running some form of a
, which is relatively easy to setup and comes already installed as a default service on many popular linux distros. Staking mina We can try out staking with our mina by issuing the following command: mina client set-staking --public-key $MINA_PUBLIC_KEY
Alternatively, you can restart the daemon with the
-block-producer-pubkey
flag: mina daemon \
-peer-list ~/peers.txt \
-block-producer-pubkey $MINA_PUBLIC_KEY
We can always check which accounts we're currently staking with, by using the
mina client status
command: mina client status
Mina daemon status
-----------------------------------
Global number of accounts: 372
Block height: 20
Max observed block length: 20
Local uptime: 1m48s
Ledger Merkle root: ...
Protocol state hash: ...
Staged Hash: ...
Git SHA-1: ...
Configuration directory: ...
Peers: 5 (...)
User_commands sent: 0
SNARK worker: None
SNARK work fee: 1
Sync status: Synced
Block producers running: 1 (...)
Best tip consensus time: epoch=0, slot=133
Next proposal: None this epoch… checking at in 5.284h
Consensus time now: epoch=0, slot=134
Consensus mechanism: proof_of_stake
Consensus configuration: ...
Addresses and ports: ...
Libp2p PeerID: ...
The
Block producers running
field in the response above returns the number of accounts currently staking, with the associated key. WARNING Keep in mind that if you are staking independently with funds in a account, you'll need to remain connected to the network at all times to successfully produce blocks. If you need to go offline frequently, it may be better to delegate your stake. If you'd like to send your coinbase to an account other than the one that is staking, you can use the
-coinbase-receiver
flag when you start your daemon. You can even point the coinbase at a cold wallet! Delegating mina Delegating mina is an alternative option to staking it directly, with the benefit of not having to maintain a node that is always connected to the network. First make sure you've unlocked your account: mina account unlock --public-key $MINA_PUBLIC_KEY
And then run this command to delegate your stake: mina client delegate-stake \
--receiver <DELEGATE-PUBLIC-KEY> \
--sender $MINA_PUBLIC_KEY \
--fee 0.1
The fields in this command: The
receiver
flag is the public key of the receiver of your stake delegation
sender
is the public key of the account from which you want to delegate
fee
is the cost to send your transaction. It is paid to the network’s block producers. Note there is no
amount
parameter. Your full Mina balance will be delegated automatically. You'll notice that this command looks suspiciously like a payment transaction. That's because a stake delegation is also a transaction! This is why we have to pay a small transaction fee in order to change this setting. Delegating your stake might be useful if you're interested in: Running your own staking node that uses funds from a "cold wallet" Delegating to a "staking pool" which will provide token payouts periodically Or if you don't have enough tokens to make managing a block producer full-time worthwhile NOTE There is a latency period of a 2-4 weeks before your new stake delegation comes into effect Compressing data in the Mina network The Mina protocol is unique in that it doesn't require nodes to maintain the full history of the blockchain like other cryptocurrency protocols. By recursively using cryptographic proofs, the Mina protocol effectively compresses the blockchain to constant size. We call this compression, because it reduces terabytes of data to a few kilobytes. However, this isn't data encoding or compression in the traditional sense - rather nodes "compress" data in the network by generating cryptographic proofs. Node operators play a crucial role in this process by designating themselves as "snark-workers" that generate zk-SNARKs for transactions that have been added to blocks. You can start a snark-worker using these commands: mina client set-snark-work-fee <FEE>
mina client set-snark-worker --address $MINA_PUBLIC_KEY
Alternatively, you can restart the daemon with these flags: mina daemon \
-peer-list ~/peers.txt \
-run-snark-worker $MINA_PUBLIC_KEY \
-snark-worker-fee <fee>
As a snark worker, you get to share some of the block reward for each block your compressed transactions make it in to. The block producer is responsible for gathering compressed transactions before including them into a block, and will be incentivized by the protocol to reward snark-workers. Snark workers can be fairly compute intensive, so if you need to limit their CPU usage, you can specify the number of threads snark workers use with the
-snark-worker-parallelism
flag. This can be especially useful if you're trying to run a block producer and snark worker on the same machine and having issues producing blocks in time. That about covers the roles and responsibilities as a Mina node operator. Since Mina is a permissionless peer-to-peer network, everything is managed and run in a decentralized manner by nodes all over the world. Similarly, the Mina project is also distributed and permissionless to join. The code is all open source, and there is much work to be done, both technical and non-technical. To learn more about how you can get involved with Mina, please check out the Contributing to Mina section. Using daemon.json to configure your mina daemon By creating a file at
~/.mina-config/daemon.json
, you can configure your mina daemon without needing to provide options on the commandline. This can be useful for running mina as a service as well as just for avoiding repetitive typing! Most of the options that can be passed to
mina daemon
on the commandline can also be provided as options in the config file. See
mina daemon -help
for more documentation of the options. Below is an example of usage of all the usable configuration parameters (in your file, you only need to specify the ones you want to change): {
"daemon": {
"client-port": 1000,
"external-port": 1001,
"rest-port": 1002,
"block-producer-key": "/path/to/privkey-file",
"block-producer-password": "mypassword",
"block-producer-pubkey": "<MY PUBLICKEY>",
"coinbase-receiver": "<MY PUBLICKEY>",
"log-block-creation": false,
"log-received-blocks": false,
"log-snark-work-gossip": false,
"log-txn-pool-gossip": false,
"peers": ["seed-one.o1test.net", "seed-two.o1test.net"],
"run-snark-worker": "<MY PUBLICKEY>",
"snark-worker-fee": 10,
"snark-worker-parallelism": 1,
"work-reassignment-wait": 420000,
"work-selection": "seq"
}
}
CLI Reference The Mina CLI (command-line interface) is the primary way for users to interact with the Mina network. It provides standard client functionality to create accounts, send transactions, and participate in consensus. There are also advanced client and daemon commands for power users. The CLI is installed when you install Mina. WARNING Mina APIs are still under construction, so these commands will likely change. See
mina help
for the most up-to-date version. Mina Accounts $ mina accounts help
Client commands concerning account management
mina accounts SUBCOMMAND
=== subcommands ===
list List all owned accounts
create Create new account
import Import a password protected private key to be tracked by the daemon.
Set CODA_PRIVKEY_PASS environment variable to use non-interactively
(key will be imported using the same password).
export Export a tracked account so that it can be saved or transferred
between machines.
Set CODA_PRIVKEY_PASS environment variable to use non-interactively
(key will be exported using the same password).
unlock Unlock a tracked account
lock Lock a tracked account
help explain a given subcommand (perhaps recursively)
Mina Client $ mina client help
Lightweight client commands
mina client SUBCOMMAND
=== subcommands ===
get-balance Get balance associated with a public key
get-tokens Get all token IDs that a public key has accounts for
send-payment Send payment to an address
delegate-stake Delegate your stake to another public key
create-token Create a new token
create-token-account Create a new account for a token
mint-tokens Mint more of a token owned by the command's sender
cancel-transaction Cancel a transaction -- this submits a replacement
transaction with a fee larger than the cancelled
transaction.
set-staking Start producing blocks
set-snark-worker Set key you wish to snark work with or disable snark
working
set-snark-work-fee Set fee reward for doing transaction snark work
export-logs Export daemon logs to tar archive
export-local-logs Export local logs (no daemon) to tar archive
stop-daemon Stop the daemon
status Get running daemon status
help explain a given subcommand (perhaps recursively)
Mina Daemon $ mina daemon -help
Mina daemon
mina daemon
=== flags ===
[--all-peers-seen-metric true|false] whether to track the set
of all peers ever seen for
the all_peers metric
(default: false)
[--archive-address HOST:PORT/LOCALHOST-PORT] Daemon to archive process
communication. If HOST is
omitted, then localhost is
assumed to be HOST.
(examples: 3086,
154.97.53.97:3086)
[--archive-rocksdb] Stores all the blocks
heard in RocksDB
[--background] Run process on the
background
[--bind-ip IP] IP of network interface to
use for peer connections
[--block-producer-key KEYFILE] Private key file for the
block producer. You cannot
provide both
`block-producer-key` and
`block-producer-pubkey`.
(default: don't produce
blocks)
[--block-producer-password PASSWORD] Password associated with
the block-producer key.
Setting this is equivalent
to setting the
CODA_PRIVKEY_PASS
environment variable. Be
careful when setting it in
the commandline as it will
likely get tracked in your
history. Mainly to be used
from the daemon.json
config file
[--block-producer-pubkey PUBLICKEY] Public key for the
associated private key
that is being tracked by
this daemon. You cannot
provide both
`block-producer-key` and
`block-producer-pubkey`.
(default: don't produce
blocks)
[--client-port PORT] local RPC-server for
clients to interact with
the daemon (default: 8301)
[--coinbase-receiver PUBLICKEY] Address to send coinbase
rewards to (if this node
is producing blocks). If
not provided, coinbase
rewards will be sent to
the producer of a block.
[--config-directory DIR] Configuration directory
[--config-file PATH] Path to a configuration
file (overrides
CODA_CONFIG_FILE, default:
<config_dir>/daemon.json).
Pass multiple times to
override fields from
earlier config files
[--current-protocol-version NN.NN.NN] Current protocol version,
only blocks with the same
version accepted
[--demo-mode] Run the daemon in
demo-mode -- assume we're
"synced" to the network
instantly
[--direct-peer /ip4/IPADDR/tcp/PORT/p2p/PEERID] Peers to always send new
messages to/from. These
peers should also have you
configured as a direct
peer, the relationship is
intended to be symmetric
[--disable-node-status] Disable reporting node
status to other nodes
(default: enabled)
[--discovery-keypair KEYFILE] Keypair (generated from
`mina advanced
generate-libp2p-keypair`)
to use with libp2p
discovery (default:
generate per-run temporary
keypair)
[--enable-flooding true|false] Publish our own
blocks/transactions to
every peer we can find
(default: false)
[--enable-mina-peer-exchange true|false] Help keep the mesh
connected when closing
connections (default:
true)
[--enable-peer-exchange true|false] Help keep the mesh
connected when closing
connections (default:
false)
[--external-ip IP] External IP address for
other nodes to connect to.
You only need to set this
if auto-discovery fails
for some reason.
[--external-port PORT] Port to use for all libp2p
communications (gossip and
RPC) (default: 8302)
[--file-log-level LEVEL] Set log level for the log
file
(Spam|Trace|Debug|Info|Warn|Error|Faulty_peer|Fatal,
default: Trace)
[--gc-stat-interval INTERVAL] in mins for collecting GC
stats for metrics
(Default: 15.000000)
[--generate-genesis-proof true|false] Deprecated. Passing this
flag has no effect
[--genesis-ledger-dir DIR] Directory that contains
the genesis ledger and the
genesis blockchain proof
(default: <config-dir>)
[--insecure-rest-server] Have REST server listen on
all addresses, not just
localhost (this is
INSECURE, make sure your
firewall is configured
correctly!)
[--isolate-network true|false] Only allow connections to
the peers passed on the
command line or configured
through GraphQL. (default:
false)
[--libp2p-metrics-port PORT] libp2p metrics server for
scraping via Prometheus
(default no
libp2p-metrics-server)
[--limited-graphql-port PORT] GraphQL-server for limited
daemon interaction
[--log-block-creation true|false] Log the steps involved in
including transactions and
snark work in a block
(default: true)
[--log-json] Print log output as JSON
(default: plain text)
[--log-level LEVEL] Set log level
(Spam|Trace|Debug|Info|Warn|Error|Faulty_peer|Fatal,
default: Info)
[--log-precomputed-blocks true|false] Include precomputed blocks
in the log (default:
false)
[--log-snark-work-gossip true|false] Log snark-pool diff
received from peers
(default: false)
[--log-txn-pool-gossip true|false] Log transaction-pool diff
received from peers
(default: false)
[--max-connections NN] max number of connections
that this peer will have
to neighbors in the gossip
network. Tuning this
higher will strengthen
your connection to the
network in exchange for
using more RAM (default:
50)
[--metrics-port PORT] metrics server for
scraping via Prometheus
(default no
metrics-server)
[--minimum-block-reward AMOUNT] Minimum reward a block
produced by the node
should have. Empty blocks
are created if the rewards
are lower than the
specified threshold
(default: No threshold,
transactions and coinbase
will be included as long
as the required snark work
is available and can be
paid for)
[--no-super-catchup] Don't use super-catchup
[--open-limited-graphql-port] Have the limited GraphQL
server listen on all
addresses, not just
localhost (this is
INSECURE, make sure your
firewall is configured
correctly!)
[--peer /ip4/IPADDR/tcp/PORT/p2p/PEERID] initial "bootstrap" peers
for discovery
[--peer-list-file /ip4/IPADDR/tcp/PORT/p2p/PEERID] initial "bootstrap" peers
for discovery inside a
file delimited by
new-lines (\n)
[--peer-list-url URL] URL of seed peer list
file. Will be polled
periodically.
[--precomputed-blocks-file PATH] Path to write precomputed
blocks to, for replay or
archiving
[--proof-level] full|check|none
[--proposed-protocol-version NN.NN.NN] Proposed protocol version
to signal other nodes
[--rest-port PORT] local REST-server for
daemon interaction
(default: 3085)
[--run-snark-coordinator PUBLICKEY] Run a SNARK coordinator
with this public key
(ignored if the
run-snark-worker is set)
[--run-snark-worker PUBLICKEY] Run the SNARK worker with
this public key
[--seed] Start the node as a seed
node
[--snark-worker-fee FEE] Amount a worker wants to
get compensated for
generating a snark proof
(default: 100000000)
[--snark-worker-parallelism NUM] Run the SNARK worker using
this many threads.
Equivalent to setting
OMP_NUM_THREADS, but
doesn't affect block
production.
[--stop-time UPTIME] in hours after which the
daemon stops itself (only
if there were no slots won
within an hour after the
stop time) (Default: 24)
[--tracing] Trace into
$config-directory/trace/$pid.trace
[--upload-blocks-to-gcloud true|false] upload blocks to gcloud
storage. Requires the
environment variables
GCLOUD_KEYFILE,
NETWORK_NAME, and
GCLOUD_BLOCK_UPLOAD_BUCKET
[--uptime-submitter-key KEYFILE] Private key file for the
uptime submitter. You
cannot provide both
`uptime-submitter-key` and
`uptime-submitter-pubkey`.
[--uptime-submitter-pubkey PUBLICKEY] Public key of the
submitter to the Mina
delegation program, for
the associated private key
that is being tracked by
this daemon. You cannot
provide both
`uptime-submitter-key` and
`uptime-submitter-pubkey`.
[--uptime-url URL] URL of the uptime service
of the Mina delegation
program
[--validation-queue-size NN] size of the validation
queue in the p2p network
used to buffer messages
(like blocks and
transactions received on
the gossip network) while
validation is pending. If
a transaction, for
example, is invalid, we
don't forward the message
on the gossip net. If this
queue is too small, we
will drop messages without
validating them. If it is
too large, we are
susceptible to DoS attacks
on memory. (default: 150)
[--work-reassignment-wait WAIT-TIME] in ms before a snark-work
is reassigned (default:
420000ms)
[--work-selection seq|rand] Choose work sequentially
(seq) or randomly (rand)
(default: rand)
[--working-dir PATH] path to chdir into before
starting (useful for
background mode, defaults
to cwd, or / if
-background)
[-help] print this help text and
exit
(alias: -?)
Mina Advanced $ mina advanced help
Advanced client commands
mina advanced SUBCOMMAND
=== subcommands ===
add-peers Add peers to the daemon
Addresses take the format
/ip4/IPADDR/tcp/PORT/p2p/PEERID
archive-blocks Archive a block from a file.
If an archive address is given, this process will
communicate with the archive node directly;
otherwise it will communicate through the daemon
over the rest-server
batch-send-payments Send multiple payments from a file
chain-id-inputs Print the inputs that yield the current chain id
client-trustlist Client trustlist management
compile-time-constants Print a JSON map of the compile-time consensus
parameters
compute-receipt-chain-hash Compute the next receipt chain hash from the
previous hash and transaction ID
constraint-system-digests Print MD5 digest of each SNARK constraint
dump-keypair Print out a keypair from a private key file
generate-keypair Generate a new public, private keypair
generate-libp2p-keypair Generate a new libp2p keypair and print out the
peer ID
get-nonce Get the current nonce for an account
get-peers List the peers currently connected to the daemon
get-public-keys Get public keys
get-trust-status Get the trust status associated with an IP address
get-trust-status-all Get trust statuses for all peers known to the
trust system
hash-transaction Compute the hash of a transaction from its
transaction ID
next-available-token The next token ID that has not been allocated.
Token IDs are allocated sequentially, so all lower
token IDs have been allocated
node-status Get node statuses for a set of peers
object-lifetime-statistics Dump internal object lifetime statistics to JSON
pending-snark-work List of snark works in JSON format that are not
available in the pool yet
pooled-user-commands Retrieve all the user commands that are pending
inclusion
reset-trust-status Reset the trust status associated with an IP
address
send-rosetta-transactions Dispatch one or more transactions, provided to
stdin in rosetta format
set-coinbase-receiver Set the coinbase receiver
snark-job-list List of snark jobs in JSON format that are yet to
be included in the blocks
snark-pool-list List of snark works in the snark pool in JSON
format
start-tracing Start async tracing to
$config-directory/trace/$pid.trace
status-clear-hist Clear histograms reported in status
stop-tracing Stop async tracing
time-offset Get the time offset in seconds used by the daemon
to convert real time into blockchain time
validate-keypair Validate a public, private keypair
validate-transaction Validate the signature on one or more
transactions, provided to stdin in rosetta format
verify-receipt Verify a receipt of a sent payment
visualization Visualize data structures special to Mina
vrf Commands for vrf evaluations
wrap-key Wrap a private key into a private key file
help explain a given subcommand (perhaps recursively)
next… docker run --name mina -d -p 8302:8302 --restart=always --mount "type=bind,source=
Run docker logs -f mina to follow the logs, and if it crashes save the log output to a file with docker logs mina > mina-log.txt and post the output to the #mentor-nodes channel or attach the full ~/.mina-config/mina.log to a github issue and link the issue in discord. Run docker exec -it mina mina client status to monitor connectivity to the network, you should quickly find at least 10 peers and watch the block height / max observed block height climb. NOTE If you encounter [Warn] Shutdown before Mina instance was created, not saving a visualization when attempting to run your Docker container, increase the resources that the Docker container is allowed to use. Checking connectivity Now that we've started up a node and are running the Mina daemon, open up another shell and run the following command: mina client status NOTE It may take up to a minute before mina client status connects to the daemon when first starting up. So if you see Error: daemon not running. See mina daemon, just a wait a bit and try again. Most likely we will see a response that include the fields below: ... Peers: Total: 4 (...) ... Sync Status: Bootstrap If you see Sync Status: Bootstrap, this means that the node is bootstrapping and needs to sync with the rest of the network. You may need to be patient here as this step might take some time for the node to get all the data it needs. After a while, your node should connect to more peers and then should move into Sync Status: Catchup, which means we're gathering the most recent blocks and state trying to catch up the the highest block. When sync status reaches Synced and the node is connected to 1 or more peers, we will have successfully connected to the network. We will also see a corresponding daemon log once we've synced: [Info] Mina daemon is now synced. If you the Bootstrap state persists for more than an hour, there may be an issue with your port configuration. Stepping up your game Now that we have a fully synced node, we can learn about some of the more advanced features of the daemon such as Sending a payment and Staking & Delegating. And if you want to earn more tokens, check out the Foundation Delegation Program.
MinaWallet
No activity yet