You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
the cold key has not already resigned (as per the committeeState stored in VState)
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.
The text was updated successfully, but these errors were encountered:
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.
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?
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:
committeeState
stored inVState
)* 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 currentGovState
).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.
The text was updated successfully, but these errors were encountered: