[1/4] Document threshold policies and security assumptions

[0xsecaas]

related to #18
related to #57

---

Part 1/4: Document threshold semantics and security assumptions across schemes

Part 2/4: Persist and enforce threshold invariants across key refresh APIs
Part 3/4: Implement scheme-specific hardcoded threshold validation
Part 4/4: Mirror threshold validation and checks in MPC repo

[gilcu3]

This cannot be accurate. During resharing we might need to change the threshold $t$, and with it $f$.
CC: @SimonRastikian @netrome

On a related note, in which cases $f = t - 1$ is not true?

[0xsecaas]

@gilcu3 true (for current implementation).

I should've mentioned in a Planned policy:
once ThresholdPolicy/SchemeRules land ([step 3/4]), the default will be:

(N,f,t) stays fixed unless the SchemeRules entry for that scheme allows otherwise.

---

The What (Goal):

Make the constraints explicit and impossible to miss.

The How (Approach):

• Modify APIs so that mismatched thresholds (e.g., refresh with different threshold) are rejected (step 2/4) unless explicitly intended and supported (step 3/4):
  • Introduce scheme-specific hardcoded rules over allowable threshold.

[gilcu3]

alright, probably in the future PRs then it will make sense. Although also maybe worth asking, do we have a variable for $f$ because at some point that invariant $f = t-1$ might not hold anymore?

[gilcu3]

for that type of comparison we should be more precise, as $N/3$ might not be an integer

[0xsecaas]

Thank you @gilcu3 for your input.

Would this be more precise?

+`f >= floor(N / 3)` in DKG 

[gilcu3]

yes, wherever we use fractions and compare them with integers we should be explicit: using floor or ceil