Hi Doc, all the data you have are correct. As there are more than 1000 Nodes now, it is normal if you wait longer than before.
We are going to publish a post so you can know the probability of having earning today. Will keep you posted.
Advanced set up: customize the port of your Node
Any update with this? My vNode appears to remain with the following status:
Beacon height - variable, increasing.
Layer - Shard
Role - Committee
Shard ID - 0
Thanks.
If the beacon height is around 350k, then there is no problem. So you are in the committee of Shard 0 and you will earn some PRV soon.
If beacon height is so less than 350k, then there is still no problem This means that your node still is synching. Please see this post. Currently, synchronization is so slow.
hey. I want to connect to external parity/infura.
I checked docker image. But I dont see inside that:
GETH_NAME is used?
@abduraman maybe you got ideas here?
My node has settled down now and appears to be working reliably.
Correct me if I’m wrong but I think ‘Shard ID -2’ means its syncing. ‘Shard ID -1’ means its waiting. And ‘Shard ID [shard numer]’ is displayed when it’s assigned to a shard in operation.
If an expert can confirm @abduraman, hopefully this helps others also.
Correct but you may earn when shard id is -1 or -2 (normally, it shouldn’t). This abnormal case may specific to the synching state. Most of the time, the correct shard id is shown. Please follow this topic for other details. As I remember, @mesquka was trying to find the issue.
Yep this seems to be correct. I’ve not had the time to work on the app but I’m hoping to do some changes to the ‘status’ field so it lets you know that the node is syncing among other things. I’m hoping to be able to get back to this in the next few days.
is it a correct return after running
rpc_port=9334 node_port=9433 ./run.sh
-bash: ./run.sh: Permission denied
Try running chmod +x ./run.sh
to add execution permissions
before doing running rpc_port=9334 node_port=9433 ./run.sh
?
rpc_port=9334 node_port=9433 ./run.sh
/bin/sh: 0: Can't open bash
Yep, before running rpc_port=9334 node_port=9433 ./run.sh
@huglester, so you following method #2 in this post? Advanced set up: customize the port of your Node
if you tail -f
the log file you may notice that when your node sync/insert new block, it sometime require Ethereum block to verify deposit proof (Eg. from ETH to pETH in Incognito-chain)
Hello
Ok I will test and get back to you.
For now will keep an eye on logs to make sure i do not break anything
parity light - does not show rpc connections
Apr 17 12:12:56 xxx parity[24356]: 2020-04-17 12:12:56 Syncing #9889294 0x16c0…a5f8 0.1 hdr/s 0+ 0 Qed 49/64 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 822 µs
Please maybe show me example strings- for which I should search so I know it actually works
EDITED:
I checked nginx proxy (I run parity behind proxy) - but I dont see anyone connecting to node in logs
Thanks
@huglester, i thought you try infura. To double check, can you show me the line of code in your run.sh
that trigger docker container?
If you running parity light, check this command docker logs -f eth_mainnet
In short, the inc_mainnet
container will connect to eth_mainnet
container to get ETH block data.
Hello
its same as INFURA. Just different link. I can try infura - but believe result will be the same. since infura also is http://… some link.
my startup is:
GETH_TMP=http://x.x.x.178/light/secretkey
; this acts like infura - I can send curl commands to it and get response
; could be like: https://mainnet.infura.io/v3/project_secret_id
docker run --restart=always --net inc_net -p $node_port_temp:$node_port_temp -p $rpc_port_temp:$rpc_port_temp -e NODE_PORT=$node_port_temp -e RPC_PORT=$rpc_port_temp -e BOOTNODE_IP=$bootnode -e GETH_NAME=$GETH_TMP -e MININGKEY=${validator_key} -e TESTNET=false -v $PWD/${data_dir}:/data -d --name inc_mainnet${index} incognitochain/incognito-mainnet:${latest_tag}
well I do not want to use parity light on same host. I wanna run it externally. is that possible?