I think it is important to update on this. Since changing my vrf keys I went a couple of Epochs then got 3 slots in a 5 Epoch series. Compare that to 72 slots with 3 slots. The trouble is everyone can keep defending the protocol by saying it was all a coincidence and just down to crap luck but what if it was not and what if the protocol does have some bias or issues at different levels. It is not fair on small pools that this issue is not at least reviewed.
2 Likes
You need to extract the VRF part of the code so that you can manually apply this function to your key, epoch nonce, and slot number. Then you can verify the previous slots you have been allocated and check future slots manually.
If you do that then your problem will be reduced to arguing that the VRF function somehow doesnât provide an even (fair) distribution.
Dig into the code. Your profile name suggests you are a mathematician / programmer.
Thanks for the advice but unfortunately my level of coding is not up to scratch with this 
I thought I would post this as an update to this conversation topic. Have a look at the diagram, which shows blocks produced by my StakePool GNP1. Two important points in time: 1. A Fork around Epoch 320 and when I changed my vrf keys around Epoch 392. It is essential to remember the following:
- I went 72 Epochs with only 3 slot allocations, which was way below the expected amount based on stake.
- I checked for slots using the CLI command every 5 days meticulously, and apart from the 3 slot allocations during this period, there were no other slots allocated.
- At no time during this period did I change the configuration of the Stakepool or change any keys or anything else except for normal KES key rotation.
- The 3 blocks minted during the period did so as expected.
- When the vrf keys were changed, there was an immediate change in luck, as the diagram shows.
- Yes the stake did increase towards the end but not by an amount that is proportional to the change in slot allocation,
A couple of members have tried to ridicule me on this, but all I can say is that there definitely appears to have been some issue here that went beyond my Stakepool. This is posted for informational purposes so that IOG or anyone who wants to can take this into consideration when reviewing their code.
This long period in time had a serious impact on my Lifetime Luck as reported on many explorers dropping from the 90 + % levels to something like 79% and I am still trying to recover from this. So yes I was annoyed.
I will not be checking anything further on this.
2 Likes
If you think your keys were somehow negatively biased then I encourage you to keep chipping away to figure out how. As a SPO you will need to do more with your pool in the future and understanding the internal workings might one day give you an advantage. I think it is worth the effort and I will try to help because I want this knowledge too.
I am still interested in being able to implement some code to manually calculate the VRF value for a particular slot using my pool vrf.skey.
Here is where the verifiable random function is applied in cardano-node to calculate the âvrfLeaderValueâ: https://github.com/input-output-hk/ouroboros-consensus/blob/main/ouroboros-consensus-protocol/src/ouroboros-consensus-protocol/Ouroboros/Consensus/Protocol/Praos/VRF.hs
1 Like
Yes - I am happy to look further into this but I would need help in how to do this - do you have a telegram or something where I could discuss further?
1 Like
I am on the matrix channels. For example this one: You're invited to talk on Matrix
Not that I will be able to help you much yet, but I am looking to try to improve my ability over time. I am going to try building a client in haskell to talk to ogmios and grab block header data to put into a sqlite database. This is basically what the cncli tool does. If I can pull it off and get something working then I will necessarily know a lot more about reading that haskell code I linked.
1 Like