Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check committee member on cold-key resignation in GOVCERT rule #634

Open
teodanciu opened this issue Dec 20, 2024 · 4 comments
Open

Check committee member on cold-key resignation in GOVCERT rule #634

teodanciu opened this issue Dec 20, 2024 · 4 comments

Comments

@teodanciu
Copy link
Contributor

In ledger, when we process a cold-key committee resignation certificate in GOVCERT, we are doing the following checks on the cold-key credential provided in the certificate:

  1. the cold key has not already resigned (as per the committeeState stored in VState)
  2. the cold key is either:
    * part of the current committee (as per the committee members stored in GovState) or
    * a candidate for a future committee (meaning: it appears in an existing UpdateCommitee proposal in the current GovState).

If any of the 1) , 2) checks fails, we are failing the rule. Our conformance test in ledger shows that in the spec, some of these checks are not implemented, because the rule is passing when we expect it to fail.

If we could implement this check in the (alternative) GOVCERT rule, we could enable the GOVCERT conformance test in ledger.

@williamdemeo
Copy link
Contributor

Thanks for making an issue for this @teodanciu! I will look at it this week.

@williamdemeo williamdemeo self-assigned this Dec 23, 2024
@williamdemeo
Copy link
Contributor

It seems to me that

  1. we already do check if the cold key has already resigned (in this line) and
  2. there's a reason we do not check if the cold key is part of the current committee (see this explanation).

@teodanciu
Copy link
Contributor Author

As we realized yesterday, the explanation seems to be about hot key registration, whereas the issue is in the resignation.
What is still left to do then for this ticket is to figure out how cc resignation is defined in the spec with respect to the conditions 1. and 2. I described.

@WhatisRT
Copy link
Collaborator

WhatisRT commented Jan 8, 2025

I think this is exactly what is fixed by #506. We originally wanted to merge all these outstanding PRs until conformance tests could detect those as failures but then decided to not wait and merge them anyway. But it seems that this one got left behind somehow.

It's a bit annoying because this was before having the two ledger versions, so the rebase might be a bit involved. I don't really have the time to do it, @williamdemeo can you take care of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants