20

9732 is the default port for P2P connections, can be overridden with --net-addr=ADDR:PORT when starting the node 8732 is the default port for RPC connections, can be overridden with --rpc-addr=ADDR:PORT All networking uses TCP. If using iptables the below rules should suffice for tezos specifically. Be aware you will need to allow other non tezos network ...


13

Here is how it works: Just to keep things simple, let's say that the chain (all the blocks included up to now) has a fitness of 100. In other words, 100 total endorsements were included on all the blocks in the chain. Your baker now has priority 0 rights to bake the next block (block #5), and you have 30 endorsements in your mempool for the previous block (...


12

@xtzbaker is spot on with the ports that the node uses. Preventing DDoS for the baking node is also one of the reasons that the most common setup for baking is to have a private baking node with trusted public nodes. Basically, we have a single node that the baker and endorser uses and it's configured to be on private mode. Private mode will disallow ...


11

The shell currently ignores a new head if it is less fit than the hypothetical next head -- baked with all the endorsements in the mempool. This hypothetical next fitness is called context_fitness in the code there. This means that if your baked block includes fewer endorsements than endorsers see in their mempool, they will ignore your block and wait for ...


9

If you key starts with edsk: do this tezos-client import secret key my_account unencrypted:edsk...


8

Most likely poor connection to peers, or at least the ones that mattered at the point in time (the endorsers for your block, and baker of the next). Endorsers will endorse the block with the higher fitness, but they can't double endorse. That means if they saw your block and endorsed it, they can't change their mind when the p1 block came along (even if it ...


6

I don't know about bakechain, but I can say your tezos-client command is incorrect. It needs to look like: ./tezos-client import secret key my_account encrypted:edesk1XXXX where encrypted:edesk1XXXX is the encrypted version of your key.


5

You could also add an extra layer of security by having your node's internet connection go through a DDoS protected VPN, like OctoVPN https://octovpn.com


3

The number of bakers on the tezos network for the current cycle is often underreported. In tezos every node validates each block, whereas bakers produce blocks (baking) and also endorse the blocks of other bakers. The link to tzscan in your question is only the bakers that baked a block, but many more bakers exist which endorsed blocks (and either missed ...


2

Tezos baking and endorsing rights are assigned on a snapshot basis, meaning whatever address you are staking with is snapshoted into the network. So no, You won’t lose your rights as long as you reuse the same wallet. You’ll want to make sure the node is synced before hand so it can bake and endorse on your behalf.


2

0x03 is for generic operations, like transfers. The ledger baking app cannot sign 0x03; it will only sign bytes beginning with 0x01, and 0x02 (blocks, endorsements). You need to exit the baking app and load the wallet app on your ledger in order to execute transfers.


2

The most significant benefit of an on premise solution is the availability of devices like the Ledger Nano S which are a proven mechanism for securing your private keys. With a cloud provider like Azure you do not have such a straightforward means to secure your keys. In theory you can make use of their dedicated HSM but it is not as clearly documented/...


1

Manager operations (which includes registering an account as a baker) cannot be applied to empty implicit accounts (empty in the sense of having no balance). So yes, you need to first reveal the account (send it some amount of tez so that it becomes non-empty).


1

Sorry to hear that! There are many different reasons why block or endorsement could be missed, such as internet connectivity etc - however we can rule out many of those in this case because we see your baker identified the baking opportunity, attempted to bake, but it seems it wasn't not able to find your Ledger device. This may be of no fault of your own, ...


1

In short, yes, you have to compile the tezos code from scratch. There is a docker option if you are familiar with that. If you are not, it's probably even more complicated to get working. There used to be a Windows-GUI option, but that is no longer maintained and ceased working properly almost a year ago. Unfortunately there is no easy button and it will ...


1

Tezster-CLI is the perfect tool to answer for your query. It will setup local nodes on your system in easy steps. Prerequisite: You must have installed docker and nodejs on your system. To install docker run the following command: (on ubuntu) sudo apt install docker.io sudo groupadd docker sudo usermod -aG docker $USER newgrp docker Install tezster-cli ...


1

Here are the updated step-by-step instructions on how to build a Tezos node(fresh Ubuntu install) become superuser sudo su update system sudo su sudo apt update && sudo apt upgrade -y install curl sudo apt-get install curl say yes to all prompts install docker sudo apt install docker.io sudo systemctl start docker sudo systemctl enable ...


1

Use the history-mode argument when importing the snapshot. These are the steps: rm -rf .tezos-node/{context,store,version.json} tezos-node snapshot import "${SNAPSHOT_FILENAME}" --history-mode=experimental-rolling tezos-node config init tezos-node run --history-mode=experimental-rolling --rpc-addr=127.0.0.1:8732 --connections=20 --bootstrap-threshold=3


1

I finally managed to get both nodes to sync and they have been working fine for two days now. Apparently the Mainnet-snapshots node got corrupted and I ended up having to export and import a new snapshot. The nodes are in the same Ubuntu 18.04 machine and were using different ports for RPC and listen. The server is behind a router but the ports are open for ...


1

I'm doing the exact same thing successfully. I have set up a remote signer and SSH tunneled it to my baking server on port 7878. It sounds from your description, and the symptom you describe, like you might have done your tunnelling backwards. The remote signer shouldn't initiate any tcp connections to your baking node. The remote signer's firewall ...


1

A lot of us bakers old timers depend on the work done by etomknudsen called "Tezos Node CPR". Main repo has systemd scripts to let systemd manage and log the tezos binaries. Systemd does a great job keeping services up as it's battle tested in enterprise level services, it handles process dependencies and restarting of services on errors. The Tezos Node ...


1

We are or hire system architects who design a HA (high availability) infrastructure for our bakers 😉 You can see some discussions here. SSH is definately one tool in the toolbelt here, but if you want a serious HA architecture you need to find skilled people to build and operate it 👍


1

This is a known problem. As discussed on gitlab, it seems to be two problems disguised as one. The first problem is poor connectivity leading to the baker waiting and missing blocks. The second problem is that the baker may have a bug where even though there are endorsements in the node it thinks that there aren't any and waits. Restarting the baking ...


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