WebOfTrust/signify-ts

Rotate should use next threshold as default value

Closed this issue · 3 comments

When building the next state for rotation it uses the current threshold state.kt to build the next state.

let isith = state.kt;

If I'm understanding the rotation logic correctly it should use the let isith = state.nt instead?

If this is the only place we build a new state the fix is easy.
But I'm not that up to speed of the entire code base. Are there more places?

When looking at signifypy they seem to have the same bug.

https://github.com/WebOfTrust/signifypy/blob/8f086a60ad15d81a78dfc3653af9e1fa5f775ac1/src/signify/app/aiding.py#L133

However Keri seems to use the next threshold when building the state.

https://github.com/WebOfTrust/keripy/blob/67eece0c00be7318f01bdf507621824e45c03bca/src/keri/app/habbing.py#L1219

m00sey commented

@daviddm to open a PR.

@m00sey create issue on signifypy

m00sey commented

@pfeairheller @SmithSamuelM can we get clarification on how this effects partial rotation?

With the new partial rotation rules (new as in 1 year old now). There is no fixed relationship between the current signing threshold in the current rotation event and the prior next signing threshold from the most recent prior establishment event (inception or rotation). The only constraint is that the current key list must expose sufficient public keys from the prior next key digest list to satisfy the prior next threshold.

A useful default would be to set the current signing threshold to match the prior next threshold and the current signing key list to match the keys from the prior next key digest list.

In a given establishment event, there is no connection between the current signing threshold and signing key list and the next signing threshold and next signing key digest list. The connection is to the prior next threshold and prior next key digest list (as I described above).. So I don't really understand the question because it is not refereing to the prior next threshold or key digest list.