Command to add trusted nodes to config
This is how I configure the node to use these "trusted nodes". I added the command to open up to 500 connections which can be left out of course:
./tezos-node config update \
Ok, i've tried to open ports, generated a new identity, added peers manually (like iguer) adviced, but nothing helped.
But a guy called "Krixt" in the Tezos Baking slack wrote this script:
# get foundation nodes
for i in dubnodes franodes sinnodes nrtnodes pdxnodes; do
for j in `dig $i.tzbeta.net +short`; do
echo "Connecting ...
Is your node in private mode ? It's bizarre to only have 5 connections while there are hundreds of peers in the networks. Have you tried to restart your node ? and/or to generate a new identity ? Maybe the other nodes have blacklisted yours.
You can either add peers with command line option --peer ADDR:PORT, or by adding them in the config.json file. Via ...
Some "just started node" sometime ends up in a situation like that and work is done to get rid of the problem.
The scenario is the following:
The bootstrap peers accept a big number of connection so there is never any problem to connect to them
Then, they send back always the same subset of their peers. And
these peers do not accept hundred of connection ...
While this does not directly answer your question, Kiln has a feature that can notify you when your Private Node loses connections.
When you configure Kiln to monitor the Private Node, include a 'minimum number of peers' in the UI. If your Private Node's peers drop below that number, you'll receive a notification.
Update 3/21/19 Core developers had pushed out a fix as of 366f64f3df266cf02a06412d6760f73626d0a2bf commit on the mainnet branch that addresses this issue that I described below.
In the setting where you have a node in --private-mode (to bake)
that connects itself to front (public) nodes, you must explicitly set
your front nodes to trust your private ...
As iguer pointed out, private mode would be one reason to cause this. But to elaborate, this happens mostly because private mode nodes are less favorable for a peer node to connect to as the private node is basically a leech to the network. It will not try to bootstrap other nodes. Private nodes will mostly just monitor to get the blockchain and fill its ...
First of all, setting connections limit to 10 is very low, you should either use the default value or use something nearer the default value which is 100. The less peer you have, the less chance you have to receive endorsements in time. Of course you have to manage a balance between a good connectivity and the processing power/memory required too handle the ...
Behind the known DNS addresses are several individual IPs with the nodes. Therefore you should use dig (from package dnsutils on debian) to connect to all of them.
When running a node in private mode, you also need to trust the address first.
Also it might be a good idea to put these nodes into your default config. See the commented alternative line.