Hot answers tagged

6

The P2P layer is part of the shell and is not amended via the onchain governance. Improvements to the existing approach are always welcome by contributing to the gitlab. People are also free to work on separate implementations of the shell and explore different approaches to optimization while still remaining compatible with the existing shell. And of ...


5

A dedicated, always online connection is better. You have a small window to bake/endorse, and if you are offline when this occurs you will miss your turns and therefore rewards. If you bake a block with a nonce, you have the entire next cycle to reveal this, which is about 2 days and 20 hours.


4

The delegators have nothing to do with the validity of the transactions signed by their delegate/baker. The delegated funds are never at risk and that is why it is always safe to delegate your tokens. The example you gave of a baker including a "bad" transaction in its block is handled by the endorsers. They will not endorse this block and the bad baker won'...


3

I found https://tzscan.io/network?state=all via this Reddit post where the current amount is around 6 800 nodes. There are two directions this amount maybe is not the absolute one, though: A) post says it does not count private nodes nor self bakers B) without state = all the amount was 79, which is significantly lower, denoting most probably ones ...


2

First of all, setting connections limit to 10 is very low, you should either use the default value or use something nearer the default value which is 100. The less peer you have, the less chance you have to receive endorsements in time. Of course you have to manage a balance between a good connectivity and the processing power/memory required too handle the ...


2

There is no direct tool to confirm if your node is functioning properly. You can use tezos-node config show to verify the running config before starting. Watch (ie: read) the output when the node starts as it will tell you if RPC is listening and on what port. Use this site: https://www.yougetsignal.com/tools/open-ports/ to determine if the P2P port, 9732 is ...


2

Flextesa's mini-net has an option --add-external-peer-port to allow other nodes. It has been used to test 1 node joining the sandbox (incl. as a baker → in order to test Kiln). I don't know of any attempt to make larger networks but it's worth a try.


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


2

You can add argument -l --log-requests: log all requests to the node to tezos-client to see the connection. Although this won't show you the headers, you can see the tezos-client -A rpcalpha.tzbeta.net ... tries to connect to http://rpcalpha.tzbeta.net:8732. To connect to https://rpcalpha.tzbeta.net:443 instead, you will want to add the following arguments: ...


1

There is a version negotiation at the initialization of the connection. You can make an incompatible version of the P2P protocol as long as it has a different version name. For the network not to be split, you need at least one node that speaks both versions of the protocol.


1

I found that this answer was the solution. Basically I run the node on machine A using --rpc-addr 0.0.0.0 instead of localhost or 127.0.0.1.


1

Verify the RPC is running by doing this on machine A curl http://192.168.1.200:8732/chains/main/blocks/head/protocols If that does not return, then you don't have the RPC setup correctly. If that does return, next step is to verify B -> A. Can you ping A from B? If not, network issue. If you can, disable iptables completely on A and try to use the client ...


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