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 \
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 ...
The --connections argument is actually a helper for setting several different configuration fields.
To see this you can use the tezos-node config init and tezos-node config update commands to convert the command line arguments into configuration JSON, e.g.:
tezos-node config init ... --connections 1 ...
In the config file (~/.tezos-node/config.json by ...
The --peer= argument allows to specify peers that node should connect to. This is how you get private nodes to connect to specific peers. It takes an ip and port.
This is from running tezos-node run --help.
A peer to bootstrap the network from. Can be used several times to
add several peers.
Use ./tezos-node config update --connections=300 to fix your config file, as Tom said, those numbers should not match. Then restart tezos-node. Make sure your firewall is open, and any routers are port-forwarding to port 9732. You should also enable the RPC while you are at it config update --rpc-addr=127.0.0.1:8732 so that you can use other tools which ...
Giganode is indeed a public node, among many out there. However, not all RPC endpoints are exposed for performance and privacy reasons. For instance, https://mainnet-tezos.giganode.io/network/points returns 403 Forbidden because they don't allow it.
If you are looking for a list of tezos nodes, you can use this popular script to get more nodes from TzKt.io ...
As a full node contains all the data necessary to participate to the network as a bootstrap peer (namely all the blocks of the chain), it is indeed possible to bootstrap a node (archive, full or rolling) from a full node.
Only the rolling nodes cannot participate to the whole bootstrap effort as they don't recall the complete chain, but only a small rolling ...
Is using a ledger with a public node possible?
Yes, I do it all the time.
this command as root, and I still see nothing
Then you have a USB and/or permissions issue. Not sure on Mac, but on linux you would check dmesg and see if the USB drivers are having an issue with the device.
Check the official support on this.
Since you are on Mac, does Ledger Live ...
Being a "private baker" simply means you are not advertising your services. There is no setting that enables you private or public baker. Technically, every baker on Tezos is public.
To be a "public baker" you simply advertise yourself as such. You must contact each of the major explorers (tzkt, tzstats, etc) and request your profile be ...
I might have found the answer from this blog post from Nomadic Labs:
An important thing to note is that running a full node is enough to maintain the full chain history. Indeed, archive nodes do not need to use archive peers to bootstrap their archive, but only full peers, as the chain data is enough to apply the chain and construct the context archives. ...
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.
The incoming connection rejected due to untrusted source is most certainly due to a previous non-private run on the same IP. Your IP is known as a potential peer, so other nodes try to connect. It is not a problem, your node will simply reject these connections.
Maybe your public node was saturated.
It is important that your public node also has your ...