Troubleshooting NANO nodes and NANO development
Work in progress. On this page, I will collect some of the most common mistakes, along with possible fixes.
Common mistakes and pitfalls when developing with NANO
- Trying to retrieve wallet IDs and seeds via RPC (only works via CLI)
- Having the IPv6 stack disabled (node will not work even though it communicates on IPv4 mostly)
- Mistaking a seed for a wallet ID (wallet ID is a local )
- Mistaking a seed for a private key (Read the key guide for details)
- Mistaking a public key for a address (addresses are Base32-encoded, pubkeys are Base16)
- Not setting firewall & whitelists correctly when trying to connect use RPC remotely (You need to set the remote host IP in the config in order to be able to connect to the node. By default, it's localhost only.)
- Exposing RPC ports to the public (setting the remote host IP in the config.json to 0.0.0.0 will expose the RPC to everyone if you don't take further measures in your firewall.)
- Trying to send funds before the node is in sync
- Relying on RPC Callback (Callback is prone to drop blocks. Have some fallback option. Increase file handler limits. Callback will only be triggered after vote quorum is met - set it high enough so you are safe from double-spend attacks (forks), but set it low enough so you still rach the quorum - 1 or 2 big representatives could go offline, and another 10% of voting weight is wasted permanently)
- Wrong IP/loopback format (- need to further test this before making recommendations -)
- Forgetting to restore all previously used accounts after importing a seed
- Having enable_control disabled
- Not restarting the node after using wallet-altering CLI commands
- Lack of redundancy, backups, and failsafe mechanisms
- Refunding to exchange wallets
- Using wrong units (1 NANO = 10^30 raw)
- Causing integer overflows by not using a Bigint library (nano balances use up to 39 digits for integers)
- Using the wrong endianness for network serialization (some endianness changed with the introduction of state blocks)
- Trying to pass decimals/floats to the Qt wallet or RPC (it will accept integers only)
- Sending amounts below the minimum_receive threshold in config.json and wondering why funds are not pocketed (only affects the creation of "receive" blocks, not the node functionality)
- Using incorrect json syntax (json-strings only, and sometimes it's necessary to have them in a single line when trying to process blocks)
- to be continued...
RPC Errors explained
'Gap source block'
When trying to make a "receive" type state block, the corresponding send block hash was not found on this node. This can also happen due to the ambiguity of the "link" field:
when you try to send funds but you made a mistake when calulating the balance, the node thinks that you want to receive from a nonexistent block.
If the block is supposed to exist, try restarting the node.
The node does not find the block hash you set in the "previous" field. Make sure that you put the current "frontier" in there. Query
account_info to get the current frontier.
'Error generating block'
"error": "error generating block" means that the account is not found in the local wallet. Probably a typo in the wallet ID. Use
./rai_node --wallet_list to see what your node actually has.
'Account not found'
account_info: Most likely means that the ledger doesn't have an entry for that account since it never broadcasted a block, i.e. it means that the account has no funds at all, or pending funds only.
account_balance will not give this error but show 0 balances instead if the account hasn't ever received anything at all.
In earlier versions, this error was also thrown when the wallet was locked, for example when using
'Unable to parse json'
"error": "Unable to parse JSON" probably means that the syntax is not correct, for example a missing argument
"curl: (7) Failed to connect to ::1 port 7072: Connection refused" means that the port is not accessible. For example, if the daemon is not running, or the remote node is not whitelisted(?)
1) Source block doesn't exist 2) Source has already been received 3) Trying to make an open bock when only state blocks are allowed since network upgrade
Previous block already has a successor that references it
'bad destination account'
"error": "Bad destination account" means that the recipient is malformed (too short or too long) or has a typo in it (checksum incorrect, illegal letter, ...)
'Invalid amount number'
"error": "Invalid amount number" means that you didn't use a integer number between 0 and 2128. It needs to be in RAW. Nano amounts (decimals/floats) are not accepted.
"error": "bad source" means that the sending account is malformed. Typos, wrong checksum, wrong prefix, wrong length, ...
'Bad wallet number'
"error": "Bad wallet number" means that your string is not a 64-character HEX string, i.e. it's too long or too short or contains non-hex-characters.
'Wallet not found'
"error": "Wallet not found" can have multiple causes. First of all, keep in mind that the node will never let you choose the wallet ID,
it always is randomly assignes as it serves some kind of extra protection when it comes to wallet access - it's almost like an API token, except that it's also used to locally assign data,
and you should do further considerations when it comes to API security.
Possible solutions are:
a) Restart your daemon after creating a wallet with CLI (not necessary for wallets created through RPC).
b) You probably mistook the Wallet ID for the seed. They serve different purposes.
c) You forgot the wallet ID? Use the CLI command `
to see which wallets that particular node's database contains. By default, you can't retrieve Wallet IDs with an RPC command for security reasons.