Does an ideal of 0.25 really mean a 25% chance of getting a slot each Epoch

I agree with that; these guys know what they are talking about.
The way I tend to think about this stuff is a binomial distribution
(your stake) / (all stake) = your chance at any block
in an epoch, there ~21600 blocks (but we lose some of them)

for example, if your pool was 250K, and 25 billion Ada total was staked:
(250e3 / 25e9) = 0.00001 (0.0010%)
In an epoch, you might have somewhat less than 21600 blocks (a bit over every 20 seconds), I typically assume about 5% lost

image

Your chance of going 1 epoch with no blocks would be 81%, two epochs would be (.81*.81), etc

With a couple thousand small pools, we do expect to see some streaks - the standard deviation is larger than the mean here

(other than the ways the fixed fees work, there should be nothing that penalizes small pools)

If you think there is something systematically wrong, feel free to send me details, I can try to get the analysis in front of the right people

4 Likes

Thanks for this and yes I don’t think there is any issue with the stats

so we would agree then that 1 slot in 40 Epochs would produce a very small chance of this happening. I agree that all these concepts are correct and of course you can have outliers in any statistical model. The guy that wins the lotto - he is an outlier that managed to defeat the odds of 1 in a million. I guess the issue is for me at what point does this no longer just become poor luck - after 60 Epochs?, 100 Epochs? - at which time of course my Stakepool will have no reputation at all for minting blocks :grinning:

1 Like

I tend to think about frequencies, so out of 2000 stake pools with 250K Ada delegated to them:

After 10 epochs (50 days): 215 of 2000 would have no blocks
After 20 epochs (100 days): 23 of 2000 would have no blocks
After 30 epochs (150 days): 2 or 3 would have no blocks
After 40 epochs (200 days): pretty much all the pools should have seen a block by now

(when observing the actual population of SPOs, there is some survivorship bias - the pools that survive tended to be a bit luckier than average)

That being said, after 40+ epochs (and 250K Ada), I would be suspicious that there is something else wrong: registrations, relays or some network thing.

2 Likes

Thanks

Yes everything has been checked more than once and as stated above there was a slot allocated in Epoch 351 during this 40 Epoch stretch which was minted successfully so no configuration issues. I also check slots allocated using the cncli query every 5 days and so no blocks lost to slot battles or stolen or whatever - also 26 blocks minted reasonably regularly prior to Epoch 320 - this is why I am a little suspicious.

There were a number of changes around epoch 320 related to block size and memory usage around that time. There were no economic / ledger rule changes.

Not sure why those would lead to any issues; someone more familiar with the hardware requirements and might be able to answer (I am aware of the changes in a general ‘read the release notes’ sense, but there may be something I missed.)

1 Like

If you are checking the leader logs with the correct information then this is deterministic. To be sure you could check using the cardano-cli rather than relying on an additional tool (cncli).

CARDANO_NODE_SOCKET_PATH='/run/cardano/mainnet-node.socket' cardano-cli query leadership-schedule \
  --mainnet \
  --genesis /etc/cardano/mainnet-shelley-genesis.json \
  --stake-pool-id "blahblahblah" \
  --vrf-signing-key-file /etc/cardano/private/vrf.skey \
  --current

Change –current to –next for next epoch (after it is 3.5 days completed).

On the other hand, if your leader log says you got allocated a slot and your block producer didn’t produce a block or it wasn’t included in the blockchain, then you have a problem. The fact that you have produced blocks in the past, and these blocks coincided with your leader logs, indicates that you are doing the leader logs correctly.

You can also look at your luck percentage on a site like adapools. If your luck percentage is significantly less than 100% then you are either failing as an operator, or unlucky, or both.

One good thing is that as a small pool you shouldn’t lose many slot battles :slight_smile:

2 Likes

Thanks

Sorry maybe I was getting my terminology wrong but this is exactly what I run to check for slots which confirms I did not get any

I can confirm that this is not the case and I do not have a problem

1 Like

There’s nothing wrong with the protocol. It’s about the people. Cardano is a tool. A hammer is also a tool. If I use a hammer to build a house, then I’m using the tool as it is intended to be used, and in a way that is useful to society. If I use a hammer to hit someone over the head, then that is not useful to society and may also be expected to escalate into a legal matter fairly quickly. In any case, there is nothing wrong with the hammer. The problem is behaviour. GNP1 seems to be raising concerns that perhaps Cardano is being used irresponsibly, even though the protocol may be functioning exactly as intended.

For example, using a familiar point of reference, I imagine how a similar conversation related to concerns about investment returns may go with a bank. I can’t imagine such a conversation going the way that the above thread went. The discussion above is more akin to what you may expect if you lost money at a casino. I would wonder about determining returns on sizable investments using what may be conceivably considered a “loot box” reward strategy in some ways.

The funds at stake are significant. GNP1 raises some very important concerns about what constitutes appropriate use of Cardano as a tool for the greater good.

CHG

41 Epochs since Epoch 320

1 slot allocated in Epoch 351 with a continuous ideal of 0.25

but of course the protocol is working fine

certainly looks like something changed after Epoch 320

@GrahamsNumberPlus1, I just wanted to say thank you for your post. I am also struggling to mint blocks as a new small pool. I do not have the amount others have when it comes to pledge and amount staked. But as you mentioned, there is a significant monetary amount investment on my part as an individual.

My hope is to mint a block (I don’t think that is to much to ask) before the cost of the infrastructure becomes to much for me to bear. Furthermore it is really difficult to convince others (even friends) to stake to a pool with 0% ROS. Regardless of anyone’s willingness to support the cause and/or network they will want some kind of return greater than 0%.

Like you I am willing to stick around and continue to be part of this amazing community. But just need some rewards to be able to sustain the pool and attract others. I believe in Cardano like the rest and truly hope to stay part of it as an SPO. This thread has been very helpful and informative.

2 Likes

Welcome to the community

This is so true and unfortunately the way the Pool Fee is set up it is completely unfair for small pools - please refer to my other post in relation to that matter ( 340 ADA Pool Fee is becoming more of a concern - #10 by GrahamsNumberPlus1 )

I have been doing this for 2 years now and it takes every bit of strength to try to find reasons to keep going right now as it is near impossible to get any returns or rewards. I only have around 300,000 ADA in stake but that was almost 1M USD worth at the height of the bull market but yet it only has produced me one slot allocation in 41 Epochs (should have been around 10) - prior to Epoch 320 I minted 26 blocks so not sure what has happened

Anyway I don’t want to put you off and it is a great community and I wish you the best of luck but I just wish they would make this whole process a fair playing field and stop protecting larger pools with the 340 min Pool Fee.

Our pool also has no block for about 20 epochs, with 300K active stake

Could it be the problem that we only have one relay?

1 Like

Hi there - now my understanding is that the slot allocation only depends on the pool being successfully registered on the network and any configuration issues and relay issues only come into play when your pool is tasked with minting the block at the specific slot (if I am wrong about this then someone please correct me). If you have been selected as slot leader in the past then things should be ok and going 20 Epochs is extremely unlikely. Have you checked every 5 days to see if you are being allocated a slot?

This is what I have been doing and I simply have not even been allocated one so minting is not relevant at this stage?

42 Now - say what you want something changed after Epoch 320

44 Epochs now - say what you want but something changed after Epoch 320

1 slot allocated in Epoch 351 with a continuous ideal of 0.25 - 0.26

but of course the protocol is working fine

surely this is at the stage where it warrants some investigation - it is just not right!

1 Like

Ok so I contact IOHK again and ask them to look into this and the response is just the same. IOHK have confirmed that they have looked into my pool and their are no technical issues with the operation of my Stakepool. They then go on to say that my pledge of 25K is small and my active stake it small and if I increase this then I should have more chance to mint a block.

Am I missing something here? I have just gone 44 Epochs with one slot allocation and I am being told that nothing is wrong. The ideal is 0.26 and has been throughout this time which means roughly a 1 in 4 chance each Epoch. This means approx 10 Blocks during this period and I have been allocated 1.

I understand this works like a lottery system but at what point are we going to start to actually question the protocol or any issues with possible vrf bias? - at 100 Epochs or 200 Epochs - which will never happen as why would any delegator stay with my pool at this point in time.

I am suggesting that this is not gamblers fallacy or extremely long runs of bad luck but maybe actually a potential issue that discriminates against small pools. Come on IOHK I deserve something more than this - every aspect of this has been examined and I don’t care what you say rolling a 4 side dice will not continue to fail to roll one number over and over and over again - it does average out over time - look at the Maths - please!

1 Like

There is nothing worse than feeling like you have to blindly trust a “block box”. Unfortunately crypto is like magic to most of us.

In order to satisfy yourself, maybe you could look at the actual formula for how to use your key to check if your are the leader for any particular slot.

I know it is something along the lines of the following:

  • Query the VRF seed for the epoch (from blockchain)
  • Query the total amount of Ada staked for the epoch (from blockchain)
  • Query your pool’s stake for the epoch (from blockchain)

Then for each slot number use your pool’s vrf key to ?encrypt? a combination of the epoch VRF seed + slot number in some format and check if the output of this function produces a number that is lower than your pool’s staked Ada divided by the total staked Ada.

The formula is something like that. Maybe @HeptaSean can properly inform us, he is super knowledgeable about this sort of difficult technicality.

If you can read Rust code, the cncli tool does the calculation. It might be easier to find the calculation in Andrew Westberg’s code rather than the IOG Haskell code base.

Maybe you could manually do a few calculations using the crypto operations for just a few slot numbers so that you gained familiarity with the formula? The crypto library functions will be available as c code and python libraries.

Maybe that would build confidence in how it works. Then you could check the result for some of the slots you were actually awarded in the past. Maybe you could write a simple function that used command line parameters for the seed, total stake, and pool stake figures, as well as the vrf key.

At the very least, going through this process would be educational for yourself and might help others feel more confident by knowing how the calculation is done if you posted the details.

2 Likes

Sorry, haven’t looked at the VRF formula in detail, just know in principle how it works. I nominate @AndrewWestberg. :stuck_out_tongue:

What I would do: Change the VRF key of the pool. How to Check if your VRF skey is properly registered to the Ledger might help in this. Especially, you have to wait three epochs for the new one to take over. (Others might comment on if this is a bad idea.)

My reason is that it is then not critical anymore if the old VRF key with which you have the problem is known. Makes it easier to get help in what @Terminada suggested, which would also roughly be what I would suggest. (And in the unlikely case that we really find a problem with the formula or code it is easier to say: “Here! Look! Here is the problem!”)

Ideally, we exhaustively check all slots back to the time, where you were still producing blocks.

And we can also plot/check the distribution of the random numbers themselves (the ones that have to go below the “limbo bar” given by your stake proportion).

2 Likes

Yes. And that will provide a good visual appreciation when you see several results that just missed by a small amount.

1 Like

I just realised from your screenshot jpg that you used the cardano-cli to check your leaderlog prior to the Vasil upgrade.

You should recheck your leaderlog now that we are post the Vasil change with the “–current” switch.

See my post here: Cardano-cli leaderlog incorrect if run before Vasil

2 Likes