Troubleshooting Chainweb
Running a Node
Peer Sync Errors
If you're running a node and getting something like this the following, then it means that peer synchronization has failed:
(InternalException (HostCannotConnect "76.170.96.97" [Network.Socket.connect: <socket: 142>: does not exist (Connection refused)])))2019-11-01T05:10:29.869Z [Warn] [chainwebVersion=mainnet01|peerId=E--IPo|port=4430|host=<some host>|component=cut|sub-component=sync|sync=payload] failed to sync peers from <some node>:7463#Asb8rw: ConnectionError (HttpExceptionRequest Request { host = "<some host>" port = 7463 secure = True requestHeaders = [("Accept","application/json;charset=utf-8,application/json")] path = "/chainweb/0.0/mainnet01/cut/peer" queryString = "" method = "GET" proxy = Nothing rawBody = False redirectCount = 10 responseTimeout = ResponseTimeoutMicro 10000000 requestVersion = HTTP/1.1} (InternalException (HostCannotConnect "76.170.96.97" [Network.Socket.connect: <socket: 142>: does not exist (Connection refused)])))2019-11-01T05:10:29.869Z [Warn] [chainwebVersion=mainnet01|peerId=E--IPo|port=4430|host=<some host>|component=cut|sub-component=sync|sync=payload] failed to sync peers from <some node>:7463#Asb8rw: ConnectionError (HttpExceptionRequest Request { host = "<some host>" port = 7463 secure = True requestHeaders = [("Accept","application/json;charset=utf-8,application/json")] path = "/chainweb/0.0/mainnet01/cut/peer" queryString = "" method = "GET" proxy = Nothing rawBody = False redirectCount = 10 responseTimeout = ResponseTimeoutMicro 10000000 requestVersion = HTTP/1.1}This can happen for a variety of reasons.
Out of date binaries
One of the most prevalent is that a node is attempting to enter the network with
out of date binaries or dependencies. For example, if a node is attempting to
synchronize with an improper version of librocksdb, then peer synchronization
will fail. The solution is to make that all are up to date with the most recent
official release of chainweb-node.
Timeout exceptions
If the synchronizing node fails to provide timely feedback, nodes will receive a
timeout exception. In general this is fine, and only considered a warning. No
cause for alarm, and nodes can sync to alternative nodes in the meantime. These
exceptions are usually post-fixed by a ConnectionTimeout statement.
Something went wrong
"Something went wrong" exceptions are thrown when an internal server error occurs due to misconfiguration. Just in case, however, consider asking in the Discord to check with us and make sure your node is configured correctly and on a happy path.
Regenerate deleted configs
Issue ./chainweb-node --print-config to create a fresh config yaml.
Mining KDA
Discover peers to mine
Every Chainweb node maintains a list of peers. If you want a list of peers to
mine, curl the /cut/peer endpoint on any node to discover its list of peers. A
good start would be any bootstrap node:
→ curl -sk "https://us-e2.chainweb.com/chainweb/0.0/mainnet01/cut/peer" | python -m json.tool | grep hostname "hostname": "foo.com" "hostname": "blah.org" ...→ curl -sk "https://us-e2.chainweb.com/chainweb/0.0/mainnet01/cut/peer" | python -m json.tool | grep hostname "hostname": "foo.com" "hostname": "blah.org" ...See if a node is minable
Keep up to date with the list of minable nodes, or to test or yourself, point
your miner at any of the available nodes and see if it starts mining. This is
easiest if you set the default log level to debug. For example:
./chainweb-miner cpu --cores 2 --node us-w2.chainweb.com:443 --miner-account <some account> --miner-key <some key> --log-level debug./chainweb-miner cpu --cores 2 --node us-w2.chainweb.com:443 --miner-account <some account> --miner-key <some key> --log-level debugBalance isn't showing up after mining a block
Proof-of-Work algorithms rely on the fact that only one winning chain is chosen after a certain length of time. In the meantime, there can be many competing chains which can become several (up to 10's of) blocks long on which you'll see your miner potentially winning blocks. When a winner is chosen and the forks resolve, only those blocks mined by miners on the winning chain will be perceived by the network to be correct, and they will be awarded a block reward. As a result, you can do mining for a while and win a ton of blocks, but if you're mining on a fork you may subsequently not see a change in balance if the fork does not win the race. The solution to this is to help contribute to a healthy distribution of hash power across the network by running your own node and making sure not to centralize your mining attempts on particularly powerful nodes.
404 Errors
Miners will receive 404 errors when miners fail to connect to a node. This can happen for a variety of reasons:
Network misconfiguration
If you do not have incoming and outgoing SSL traffic enabled on your router, miners will 404. Please make sure that you have the correct router configuration. NATs tend to be a problem if you are running on AWS. Make sure this is off.
The node is down
If you receive a 404, the node may be down. Diagnose this by either pinging a
node with ping -c 3 <node ip> and seeing if it pings back or sending a cURL
request to a node's health check endpoint:
curl -k https://<node-ip>:443/health-checkcurl -k https://<node-ip>:443/health-checkA healthy node should return the following:
Health check OK.Health check OK.If a node is down, simply switch your miner to a new node which is up. In general, bootstrap nodes should always be up for mining, but it is usually fastest to mine to a peer due to lower congestion rates.