I thought I’d successfully set up my Stakepool by following the Coincashew guide. I managed to find out when I was scheduled to mint a block, but that slot came and went.
After some more digging, it looks like I’m running two relays and no block producer! - I’m confused where I’ve gone wrong. Where do I specify to start a block producer instead of a relay? - I’ve double-checked the below and that seems correct:
But the Cardano Audit script seems to think both nodes are set up as relays. And gLiveview doesn’t show any block-producing info at the bottom on either node. Which I’m assuming means they are both running as relays?
Any help is appreciated as I’m lost now, as I thought it was all correct!
If you followed coincashew guide, i think you probably missed the part where you update your starting script “startCardanoNode.sh” with KES, VRF and Operation Certificate. (PART III OPERATION - Generating Keys). If you don’t do that, your node basically starts as a relay node.
Thanks Kirael, I can see that now. I missed that section as I was generating my keys using a ledger instead, so I followed this guide instead for that bit:
I found the logs and can’t see anything around the time when I was supposed to mint a block. It’s just the same repeating “Cardano.node.LeadershipCheck:Info” and “Cardano.node.Forge:Info” lines.
I’ve spent a whole day trying to dig down this rabbit hole now and at the point of de-registering. Surely it shouldn’t be this hard to track down issues
What’s even more confusing, is I’ve setup “cncli” today and that reports a different “assigned slot” for the current epoch to what the “cardano-cli” command returns? - So even more lost now!
Hi. I would like to give also my feedback on this as I faced the same issue.
In coincashew guide, Generating Keys for the Block-producing Node section guide asks you to run the following:
cat > $NODE_HOME/startBlockProducingNode.sh << EOF
DIRECTORY=$NODE_HOME
PORT=6000
HOSTADDR=0.0.0.0
TOPOLOGY=${DIRECTORY}/topology.json
DB_PATH=${DIRECTORY}/db
SOCKET_PATH=${DIRECTORY}/db/socket
CONFIG=${DIRECTORY}/config.json
KES=${DIRECTORY}/kes.skey
VRF=${DIRECTORY}/vrf.skey
CERT=${DIRECTORY}/node.cert
/usr/local/bin/cardano-node run +RTS -N -A16m -qg -qb -RTS --topology ${TOPOLOGY} --database-path ${DB_PATH} --socket-path ${SOCKET_PATH} --host-addr ${HOSTADDR} --port ${PORT} --config ${CONFIG} --shelley-kes-key ${KES} --shelley-vrf-key ${VRF} --shelley-operational-certificate ${CERT}
EOF
This actually generates a start-up script (startBlockProducingNode.sh) which is different from the one produced since the beginning of the guide (startCardanoNode.sh). So what actually needs to be done is to replace the content of startCardanoNode.sh with the content of startBlockProducingNode.sh. This is not mentioned in the guide and can be confusing. One more thing, if any moderator/developer is reading this, in the command CONFIG=${DIRECTORY}/config.json I believe the BP node should use config-bp.json or not?
I agree the instructions are misleading. What was more frustrating is even after correcting that and running the node “successfully” for several epochs it still just missed its expected slots for no apparent reason.
I spent hours trying to solve it and got no where, as there were no errors, pointers, logs or anything else that helped isolate the issue.
I’ve worked in IT for over 30yrs and never been so frustrated with an issue tbh. In the end I just unregistered the stake pool and shut it down, as I was losing too many staking rewards.
It really shouldn’t be this hard to diagnose issues tbh.
Thanks for raising these issues with the CoinCashew guide, @geekyd There is now a pull request with fixes and improvements.
I agree with you that diagnosing issues should be easier. The CoinCashew guide was written by many different contributors without independent quality assurance, review or testing. The Cardano Node software is also in constant flux and unfortunately the guide has, at times, been quite neglected.
There persists a bias in the Cardano community towards encouraging people to delegate to existing stake pools rather than to set up their own. Sorry to lose you as an SPO. First setting up a stake pool in a Testnet environment (Preview, for example) is a good way to test stake pool configuration without risking losing rewards.
As an open-source, community-led project, CoinCashew remains committed to continuous improvement as well as addressing errors and omissions in the content as they may be identified and reported. The best ways to reach CoinCashew are creating an issue on GitHub or via Discord