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


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


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.


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

The Testnet formerly known as "Alphanet" is now called "Babylonnet". Public node address: https://rpcalpha.tzbeta.net/ Future Testnets will get the name of the actual protocol. More Infos here


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

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


2

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


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


1

You can use SmartPy Nodes curl https://carthagenet.smartpy.io/version should work fine


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

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

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

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


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