4

This means that you try to inject an endorsement in your mempool for a block that wasn't the head block. Maybe the chain reorganized between the time your endorser started preparing an endorsement and the time it was injected. This can happen but it should be very rare.


2

Based on reports from community members, the most effective way to repair the connection between Kiln and the Ledger device is to remove the baker from Kiln using the baker tile's menu, then re-add the baker. If you'd like to try signing something before taking this step, I recommend setting the highwater mark or re-authorizing the Ledger device, also from ...


2

This is correct but extremely and dangerously (for yourself) optimistic. Yes, in theory, as long are the 2 nodes you attach an endorser to are perfectly aligned "It's the same block, and the same endorsement slots. [so] the same operation hash, which is just a duplicate; not a double." But, necessarily, in practice, there will be a time where the 2 nodes ...


2

It's a compromise between convergence speed for consensus and not having too large of an overhead per block. Why 32 specifically? It has to be some number, and 32 is a nice round number.


2

The lockup for rewards is the same - i.e. rewards are released when the security deposits are.


2

The error logs clearly suggest that the ENOTTY error for the "auth" key is your problem. You cannot directly use an encrypted key to authenticate the docker daemons to a remote signer, because you cannot type the password in. (As FLF OCP notes, "the ENOTTY error is coming from an attempt to ask the key password on a terminal, but there is no such terminal")....


2

The docker implementation with tezos is bad. https://gitlab.com/tezos/tezos/-/issues/548 It does not allow for many configuration parameters to be customized, and hard-codes many parameters too. For your specific case, this can be solved by using an external mountpoint as the storage for the node like this: -v /opt/tezos/node_data:/var/run/node/data Start ...


1

For high availability, you should already have a 2nd tezos-node running and sync'd with the network. If you need to move baking operations to the backup server, best is to copy the ~/.tezos-client/ directory from server A to server B. Then you can start the baker/endorser on server B. You will be punished HARD if you double bake or double endorse so make ...


1

For that step you'll need to edit the content of the two file mentioned, replacing <proto> in the name with the protocol you intend to use, and setting the alias(es) to the BAKER_ACCOUNT and ENDORSER_ACCOUNT options in them. For example (at the time of writing, Ubuntu packages version 9.0-1), if you are using edo2net and the alias for your baker ...


1

You need to be sure you're running PtEdo2Zk tezos-baker and tezos-endorser instead of PtEdoTez. Your tezos-baker should at least provide low priority baking rights.


1

There are no URL's involved in running a tezos node. You can run a node anywhere and it will connect to the P2P network. You can put your node in private mode, which means that other nodes will not include your node in their broadcast lists. Some bakers run a setup where they have several "public" nodes, and 1 "private" node which only ...


1

If your node is configured using defaults, then your tezos-node should be listening on 127.0.0.1:8732, which you already have a rule to allow (loopback). If the endorser cannot talk to the RPC, it will immediately die and will not start back up so this is easy to test. What was the message in the endorser? Did you inject the op yet still miss? Did others ...


1

Are there any other commands polling the ledger at the time of baking/endorsement? For example if you run tezos-client list connected ledgers this will block the communication and could cause the baking/endorsement to fail. If you want to double check the communication between tezos client and ledger without waiting for an endorsement or baking, just ...


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