I suppose to assigned 10 block in this epoch (according to leader logs). But today I missed 2 (I suppose get 2 today).
In my BP node gliveview it already show leader: 2
But, Adopted: 0. I don’t know why it doesn’t make it. Did anybody ever experience this kind of trouble?
And what I’ve done wrong?
Are you sure your operational certificate is still valid? Other than that, if you’re connected to suffient peers and synchronized, nothing comes to my mind…
1 Like
Hello,
- check if your BP/relays have peers connected and tx processing…
- check if your certificates/keys are valid
- check the logs (if you know the slot number expected will be easy)
Cheers,
1 Like
I got same tip so I am renewing the op-cert several times. And now waiting for the next block. I’ll keep you posted. The peers I having trouble with topologyUpdater and still looking what’s the problem.
Thanks
The BP is connected and tx processing.
I just renew several time for the KES and also renew my op-cert
Ok, I want to confirm that the main problem is the op cert. Even if your KES still valid, just renew it. I renew my KES 5 times. And viola… everything back to normal. Thank you guys.
1 Like
Hi all,
Just a quick question. Shouldn’t the bp throw an error if there is an issue with keys or opcert?
Cheers,
A
Hi,
I never was in that situation but I see that there are some warnings configured
Hi @Alexd1985,
thank you for the quick feedback. I have not experienced the invalidity of the kes key either. I monitor its current state through a dashboard and that has always been enough. Having said that, my interest in this topic arose given the current “dry” period, during which my pool is minting far less than expected. This particular topic has been brought up here: Slot leader schedule & historical assignments So, @ADA-INDO’s post got me thinking: what if I have a problem with KES, VRF or CERT, which I cannot see?
Since then, I have looked through logs and have found 0 instances of assigned blocks (is_leader), so I guess I am not being assigned blocks to mint. Patience 
Back to the original question, what I meant was: if there is an issue with KES, VRF or CERT, the BP will throw an error on startup, right? Or am I missing something?
Cheers,
A
PS punctuation and grammar edits
This is also what I’m thinking too. But, when I ask in the Telegram group they say that it is find (because my delegation is so low) Which is very believable. But, I just knew that when I got delegation from CF. All now are clear.
FYI: I check every leader logs each epoch and it said it is zero.
1 Like
Thank you. So, there were no issues with your op-cert? It was just a bad luck streak, coupled with a small delegation?
I am having the opposite, i was very lucky when i had a small delegation, and now not so lucky even if i have received IOG delegation🙏
Patience is the answer if that’s the case. I wish you all the best for your operations!
Cheers,
A
There were an issue with my op-cert. Even it is not expired yet, but, After I renew several times it just work. I don’t know why. But, my problem is solved.
This happen again to me. I missed my block today. Just like the first one. I just renew my KES. My KES is suppose to expire on end of July. But, I think I renew this epoch. After renew, the leader is there, but not adopted (Just like my previous case).
I have been renew my KES 3 times since the first incident and everything was fine. Now, I just renew again with 5-6 times renew.
I will refund the reward for all my delegator. I’ll wait next epoch.
However, my question will be
- Anyone have same experience like this?
- Are there like specific timing when we execute this renew KES?
- Are you always renew 5-6 times each time renew KES?
Any advise will be appreciated.
Thank you
check the logs, what was the reasson?
in my case it was an issue with KES counter
I’m sorry, what’s wrong with KES counter? Do you mean Cold.counter? I use the KES value 270. I believe it is the right KES when I renew. If the time I renew the KES is 270, should I use 271 (the value)?
U must check inside the logs what erros was in your case… I had an issue with KES counter if u are looking to my screenshot
Hi @ADA-INDO and @Alexd1985,
Regarding the KES key renewal and subsequent making of the new op cert:
-
please ensure that you have permissions on the cold counter set correctly (these must be -rw for you);
-
when selecting the KES period to start, please do current period -1. This issue was resolved (i think) many months ago, but i still do it this way and never had an issue (eg if current period is 270, starting period is set at 269).
Please let us know how you go and all the best!
Cheers,
A
1 Like
I am using cntools so should not be any issues rotating the KES… I did it before but I can’t figure it out why this time I had this issue… everything was fine on grafana (the new period updated, etc)
Thank you all for all your support.
After careful investigation. I know what I’ve do wrong and why I got this problem from the first place and happen again.
Here’s my problem.
I store all my keys in USB and I delete all keys in my cold machine. I didn’t know that the cold.counter are changing after we renew KES. So, each time I renew KES (previously) I always take my keys from my backup which “next certificate issue number:” is always 1. And this also give me an answer that I need to rotate 5-6 times each time I renew my KES (previously), and this number will become around 6 or 7 or any number that is bigger then Previous KES number.
Then this time I rotate 10 more and store the renewed cold.counter to my backup. So in the future I just continue from the last one. (not start from 1)
Thank you again everyone. I really appreciate all your help.
Here is the transaction ID
f596cc4b81f6b157d86c6479a1ec504e05f2778158793fdbf8db486ec2cff2b3
a6f2f5db975541194b0c786845c13633a618e7ae4448d9a1e7dbcb7322b61283
fbdc9b0a1c7d3e74242f6aeb69f201e269294129a3c9aefeb90834a425e30f8a
9016f26f7eecd0e7af976f89ad3e8dfb0969cacd36a902201f17dd4e8ef69223
e52cd9068e104bb6f704abc02754de7bb77538c28b1a0573d3568a17911b90ce
6d294449e13e460bb7ccb74f920ac3c849c976a157d2f83fe754fb303bae6a12
c2eee27933a6ca52413d37ad9f97f4d0ef24161cf02c2f05906e8aca8454e58f
1117265d1d57c45eb285d42f16722cd4323d7af4402fe2420c8af0970478b7b9
c220e0cfae6a64586a10a4bf27fcd1814a61b545f9bdb83ef95b22f24a765917