[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?

[0xsecaas]

Not yet; today we only persist threshold and infer f = t − 1. To allow future schemes where t != f + 1, we should add explicit (N, f, t) metadata (ThresholdMeta) to keys/shares/transcripts and pass f (or at least store it alongside t) so the validator can enforce or relax the relation via SchemeRules.

Updated part of the document: link

[gilcu3]

I am still torn by:

**The tuple `(N, f, t)` chosen at key generation is fixed for all subprotocols**  
(keygen → presign/offline → signing → refresh → resharing).

I would reduce it to presign/offline → signing → refresh as for keygen and specially resharing we need the ability to change the parameters in the tuple

[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

[0xsecaas]

+Treat this as a `ThresholdMeta` record that every subprotocol must serialize and verify.

+Keep `f` explicit even when `t = f + 1`. The current schemes tie `t` to `f`, but future `SchemeRules` may relax that relation; persisting both prevents silent downgrades if a protocol later allows `t != f + 1`.

[gilcu3]

@0xsecaas is this ready for review again?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.46%. Comparing base (1e03b9c) to head (5a90b6c).
⚠️ Report is 9 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #221      +/-   ##
==========================================
+ Coverage   87.92%   88.46%   +0.53%     
==========================================
  Files          41       50       +9     
  Lines        9046     9733     +687     
  Branches     9046     9733     +687     
==========================================
+ Hits         7954     8610     +656     
- Misses        645      673      +28     
- Partials      447      450       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gilcu3]

There are some inaccuracies that we need to agree upon here. Lets follow the conversation in the PR comments

[gilcu3]

what do you mean by "design choice; distinct from N - f"?

[0xsecaas]

When I say the DKG uses a design choice, I mean its threshold is explicitly set to t = f + 1 because that’s the minimum needed to block f colluding adversaries from recovering the secret.
This is not the same as N - f, which is simply the worst-case count of honest parties.

They differ for a reason: tying t to N - f would force every honest participant to be involved in reconstruction. Using t = f + 1 avoids that—DKG security only depends on resisting f adversaries, not on the total number of honest nodes. It keeps the quorum minimal, avoids accidental assumptions about honesty counts, and gives better liveness under churn.