i am really sad. We couldnt mint our block today. Here is the error msg:
(HeaderProtocolError (HardForkValidationErrFromEra S (S (S (Z (WrapValidationErr {unwrapValidationErr = ChainTransitionError [OverlayFailure (VRFKeyWrongVRFKey)
(“failures”,Array [Object (fromList [(“kind”,String “VRFKeyWrongVRFKeyOVERLAY”)
As you have to know:
I think i did a mistake right at the beginng with the “cold-key” node.counter file. As i setup the stakepool we changed the ticker one time, next we changed the pledge and so on. At one time i think i used an “old” backup file of node.counter. At the moment it shows the next number will be 4. but we changed the pool infos 5 times
What i did 4 now was: i updated our pool margin and updateted our kes rotation files again and got no errors. but is there a way to check if this could fix the problem or do i have now a fatal problem cause of the maybe wrong node.counter file ?
Or may it possible to create a new cold.counter („delete“ the old) and then create a new node.cert … then do the pool registration process again and at last do the kes, vrf verification process again again ?
I am now also wondering: when you rotate your KES, a new counter file is created. Isn’t that always the right one with the right number? In other words would you not always fix this possible problem by just rotating your kes? Or will the newly created counter file also be wrong if the previous one is wrong?
yes thats what i thought. but it looks like that doesn’t work. and i think if i would try to setup a fresh node.cert (1st i would make a new kes pair, 2nd create new node.counter, node.skey and node.vkey, and 3rd make a vrf key pair, 4: reregister pool) that would neither fix the problem or can i connect my old poolid with the fresh certificates?
just an example node.counter 1 : 123 / node.counter 2 : 123456 / node.counter 3: 123789 / 456 are missing cause of an kes update with the wrong node.counter
that’s the question my friend. you can compare like losing the node.counter file relating to node.cert otherwise the node.counter file would not be necessary i think.
Do not delete your node keys!
Just repeatedly run any command that increases node.counter value. Do it so many times until you are sure the counter value is higher than it was before you overwrote it from backup. Then it will work for you again.
i won’t delete them but i am not sure this will work. because no one would need their node.counter file associated to the node.vkey then. to increase the counter i need to update the kes files again.
correct me if i am wrong but don’t the blockchain checks earlier vrfkeys, like is the previous hash deregistered correctly and the new one registered correctly.?
The node.counter is a security measure. If your node.cert is stolen, they can impersonate your pool. Luckily for you, you can generate a new node.cert (auromatically with higher counter value encoded inside). The network accepts the node.cert that has highest counter value and rejects all others.
Just run cardano-cli node issue-op-cert .... several times. You can watch the counter value increasing cat node.counter
When you are sure your counter value is high enough, take the node.cert and copy to BP.
i won’t delete them but i am not sure this will work. because no one would need their node.counter file associated to the node.vkey then. to increase the counter i need to update the kes files again.