13

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 \ --peer="dubnodes.tzbeta.net:9732" \ --peer="franodes.tzbeta.net:9732" \ --peer="sinnodes.tzbeta.net:9732" \ --peer="nrtnodes.tzbeta.net:9732" \ -...


7

Looks like a good start. Unless your (4G)-router has a battery consider an uninterruptible power source (UPS). A second laptop with signer and additional ledger on standby in a separate location close by will improve HA in case of hardware problems, fire/water damage or a prolonged power outage. Probably more important is your software setup. Does the ...


6

I saw an answer to this on Riot for the same question: You could change the IP address of the node. If other peers know your IP address you cannot do anything against connection attempts. I would recommend that you create a node in private mode, then create a public node, connect the private to the public one and then sync the private through ...


6

If you want to remain in private-mode, you must provide an argument --peer node:port when starting your node, or edit the config.json file of the node to add such peers (which is better, as it will be used everytime you restart it).


6

When you launch the docker node with ./mainnet.sh start, you can add extra arguments such as --private-mode --peer AAA.BBB.CCC.DDD:PORT (you probably need to specify --peer to connect your private node to your public node).


6

The node can be set in private mode with the option --private-mode It doesn’t connect to any peer other than those provided with --peer or in bootstrap-peers


6

Here is whats in my consig.json: "dubnodes.tzbeta.net ", "franodes.tzbeta.net ", "sinnodes.tzbeta.net" , " nrtnodes.tzbeta.net"


4

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. https://gitlab.com/obsidian.systems/tezos-...


4

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 ...


4

This is caused by an awkward behavior of the docker entrypoint script: it passes the node options along to tezos-node config {init,update} every time, which means options can accumulate and become impossible to remove through the entrypoint. :( One option would be to just delete your config.json and start over: ./mainnet.sh shell, then in the shell rm /var/...


3

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 ...


3

Here is the full list given by the maintainer of the foundation nodes: dubnodes.tzbeta.net franodes.tzbeta.net sinnodes.tzbeta.net nrtnodes.tzbeta.net pdxnodes.tzbeta.net I use those mainly.


2

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. --peer=ADDR:PORT A peer to bootstrap the network from. Can be used several times to add several peers.


2

It's not possible; the config update command does not support setting private-mode back to false. You could edit the config file by hand, e.g. changing "private-mode": true to "private-mode": false. By default, the config file is located at ~/.tezos-node/config.json. Another option would be to use tezos-node config reset ...your options..., which will ...


2

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 ...


2

Yes, open this port to the world. It allows others tezos nodes to discover and connect to you. Block all ports except 9732 Private mode simply tells other nodes that you do not accept incoming connections. This will lower the number of nodes that you stay connected to. There are no security concerns regarding the node itself. The node has nothing to do with ...


1

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. ...


1

Is is not possible to connect from another node to a node that is in private mode. You must establish the connection from the private node to a trusted node, not the other way round. Although the node that is connected to does not need to trust the private node to allow the connection, it is recommended to have this setting in its config file to have a ...


1

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. ...


1

Calling tezos-admin-client p2p stat on node B will list among other things, all active connections. The connections to private node will have the word private near the end of the line. Here is an example in sandbox where 127.0.0.1:19732 plays the node A (private and trusted): $ tezos-admin-client p2p stat GLOBAL STATS ↗ 4.21 kiB (224 B/s) ↘ 1.70 kiB (89 ...


1

Generally we can use the tezos-admin-client binary to add new peers: ./tezos-admin-client connect address <node ip>:9732 But the latest version of the binaries as of today (7/3/2019), the above does not work for nodes in private mode. Another approach is by calling the /network/points/{point}/trust rpc route, example: > curl http://localhost:...


1

These are settings of my private node which are registered in config.json { "data-dir": "/usr/data/.tezos-node", "rpc": { "listen-addr": "127.0.0.1:8732" }, "p2p": { "bootstrap-peers": [ "A.A.A.A:9732", "A.A.A.A:9732", "A.A.A.A:9732" ], "listen-addr": "[::]:9732", "private-mode": true, "limits": { "connection-timeout": 10, "min-...


1

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 ...


1

If you are running in --private-mode, you don't need to allow any inbound TCP connections on port 9732 from peers. Block those connections on your firewall, or with iptables. Then you will no longer receive those messages in the Tezos node software, and your node will be protected from attempted inbound connections. In general, the connection attempts are ...


Only top voted, non community-wiki answers of a minimum length are eligible