Please help with checking my Stakepool configuration

Since only the stake pool id and the VRF key go into the leaderlog computation, there is not so much that even can be the issue.

You said above that you checked the hash of the VRF key? Also that skey and vkey belong to each other?

If you are using the wrong stake pool ID – one with a lot less stake – that could fit the behaviour you are seeing.

1 Like

Thank you for providing help here - it is much appreciated. I have checked my pool id in the /priv/pool/GNP1 folder and it is the same as what is registered on the network. I have checked the hash of the vrf.vkey and again it is the same as what is registered on the network. I am not sure how I would check that the skey and vkey belong to each other but these are the only two vrf keys that I have which were created when I set up the pool so I would assume that they have to be. So not sure what else I can really check in this area.

I am getting quite concerned about this now and I am afraid this may never be solved. The reason is that I am now starting to lose the remaining stake that I have and as I do so the chances each Epoch of being selected will naturally become less and approach 0. While everyone is suggesting this is just based on luck I cannot help but think something else may be wrong and the sad thing about it is that I may never really know.

25 Epochs now and still no blocks assigned!!!

With an estimated block odds of 0.24 I am doubting this is just poor luck

I am bit surprised that there is not more interest with regards to this from the development team. At what point do we start to question the protocol? when the odds are 10,000,000 to 1 instead of 1000 to 1?

The question has to be asked is why did my pool mint 26 blocks in a reasonably regular fashion and now has just stopped being included in the protocol for 25 Epochs?

26 Epochs now and still no blocks assigned!!!

What the heck has happened? Why does a perfectly functioning Stakepool which successfully minted 26 blocks over 18 months or so suddenly stop being allocated blocks for 26 Epochs after having an average stake during these 26 Epochs of 300,000 ADA?

Did you also check that this folder is really the one used in env? There should be a line POOL_NAME="GNP1" there. (Assuming that you are using CNTools, since Coincashew doesn’t have those /priv/pool/ subfolders.)

You have made the impression that you really checked everything. So, really, really bad luck is the only explanation left. But that’s easy to say, since it’s not my own pool.

There was another thread here lately with pools with bad luck:

But, from those MOTO by @Judofish and AZ5 by @dvekris had blocks in the meantime: https://adapools.org/pool/d5e493b834ee233104cff9d141ffae2d8d76a563f829e78987540046 and https://adapools.org/pool/11049c12ebde61e94531eb2d022b44ba4fdbc48eea14bf6cbf2a6f44

PLBPL by @nanap also has an ongoing stream of bad luck: https://adapools.org/pool/51120922fb9d7c0ecbb20378950da7880cb6dd9d3c9e06e17bff6aca Not as long as yours, though.

If there is a problem with your pool, it is very rare and well-hidden.

They don’t usually read the forum that intensively.

1 Like

There was also this thread lately, where cncli gave a wrong leaderlog, because the database was not up to date if I understood that correctly:

Did you continue to cross-check with cardano-cli query leadership-schedule?

Thank you for your time with this - I really appreciate that - to answer your questions - yes I do have the line POOL_NAME=“GNP1” in the env file and I have checked that it is not commented out - #POOL_FOLDER=“${CNODE_HOME}/priv/pool” is commented out but that should not matter as everything is set up as the default settings used for cnTools.

Also yes I do check using the cardano-cli query each time and just get an empty result

This is getting really difficult now as I am not sure what I should say to my delegators - is there anyway I can contact someone from the development team to look into this as if this is a very rare and well hidden issue it would have to be in the interest of all pool operators to know. Once again thanks

https://iohk.zendesk.com/hc/en-us/articles/900001957643-Stake-pool-operator-support-and-help says to use https://iohk.zendesk.com/hc/en-us/requests/new.

Sorry, don’t know of a more direct way.

Interesting would be a tool to do the leaderlog computations for all epochs back to the ones, where you were last assigned blocks to see if they – at least – are shown correctly. I haven’t seen that in cncli nor cardano-cli as an option or is there?

1 Like

Many thanks for that - I will look into it - appreciate your help

https://pool.vet/#GNP1

Thanks but it appears to pass everything on this site Only issue is extended metadata missing which should not matter

27 Epochs now and no slots assigned !!!

That’s a long stretch… but looks like bad luck.

1 Like

Yes - I am hoping it is just down to luck. Trouble is if I keep losing stake because of it then I may never know if the chances to mint a block become too small :grinning:

If you go much longer I’ll move some ADA over and ask some delegates to move over to try and pop a block.

1 Like

That would be fantastic if that could be done - I feel bad for my delegators at the moment as I just cannot be sure that everything is OK until a block comes through. Also if you did that I would be happy to reimburse the pool fee component (340 ADA) on a proportionate basis to anybody who helped out if any block was produced.

1 Like

28 Epochs now in a row

I am going to do the Maths on this. I think I am right but someone please feel free to correct me if I have assumed wrong.

With an ideal of 0.23 this would indicate that each Epoch I have a 23% change of being selected a slot leader. That would mean a 77% of not being selected. Ok to go 2 Epochs in a row the chances of not being selected in 2 Epochs is 0.77 * 0.77 = 0.593 or about 59 % - three Epochs in a row would be 0.77 * 0.77 * 0.77 = 0.45 or 45% chance and so on.

My calculation for not being selected for 28 Epochs would be 0.77 to the power of 28 or 0.000663 equating to 6.6 chances in 10,000 or around one in 1515.

Ok I know this is the odds from the beginning and each Epoch has the same chance of selection being around 0.23 or 23 % but right now the chances of 28 Epochs in a row without selection is ridiculously low and I am suggesting there is something wrong here. Also my ideal has been as high as 0.32 at times as well which would make the odds of this happening even more unlikely.

I have had email communication with IOG and they tell me the pool is OK and this is just down to luck.

Is there something fundamentally wrong with my understanding of how the Ouroboros protocol works? I believe I understand statistics and Maths and yes I know that things based on chance can have different outcomes but something does not appear to add up here.

Similar thing happened to me once when I moved node to another machine. Resetting KES did the trick.

It was on testnet and the pool had a lot of staking (nsp11). So I could spot the error very quickly.

1 Like

Thanks - I have already rotated the keys once but maybe I will try again