wait for producer first…
and the hash for vrf local file is the same with the hash from cardanoscan.io right?
Yes whats the command I can show you.
cardano-cli node key-hash-VRF --verification-key-file path_to_vrf_file/vrf.vkey
the output should be the same with vrf hash from here
Do you think it could be an upload speed problem?
I need to contact them again to ask why its so slow.
U checked lst days inside the log files and I saw that the Producer didn’t expected the block…
What do you mean? I could only find one log file with the most recent epoch.
{"host":"block","pid":"1820","loc":null,"at":"2022-02-04T23:12:24.00Z","ns":["cardano.node.Forge"],"sev":"Info","env":"1.33.0:814df","data":{"val":{"kind":"TraceNodeNotLeader","slot":52450053},"credentials":"Cardano"},"msg":"","thread":"1746","app":[]}
for me is meaning that the cncli is reporting fake blocks
What does this mean? So why is it reporting fake blocks? Should I start a new thread?
check inside nano cncli.sh
did u added the full path for the vrf files (manually)
Ok, set the pool ID and the path for 2 vrf files … and uncomment the lines… run again ./cncli.sh leaderlog force and let’s see of will return something else for epoch 319
How do I set the path/?
/opt/cardano/cnode/priv/pool/ ?
/opt/cardano/cnode/priv/pool/skull/vrf.skey
/opt/cardano/cnode/priv/pool/skull/vrf.vkey
and don’t forget to uncomment the lines (delete #)
Ok, case closed… u didn’t lost any block… fake report
1 Like
The topology_Updater is running?
Try to run ./topology_Updater.sh
and this should be the relay, because on BP u should not use topology updater