ask-3: does an M-of-N threshold over a window replace guardian turns and grace rules?

Answer. Partly. An M-of-N threshold with a window removes the *per-guardian turn limit*. There are no turns, so a thief gains nothing by making any one guardian unreachable: up to N−M missing guardians cost the recovery nothing. It does not remove the *grace rules*. Their job moves from each guardian's turn to the approval window as a whole. The window is now the thing an outage has to outlast. A thief who keeps more than N−M−k honest guardians unreachable for one window (k = guardians the thief holds) makes that attempt fail. That costs one window per attempt, the same bound our cycle-61 cap gave per pass. Fewer than M guardians do not let a thief take the wallet. What they buy depends on who holds the veto. If the owner key can veto, the key alone lets a thief block every recovery for as long as they like, and the k guardians add nothing. If only guardians can veto, or the key cannot veto, k guardians mainly buy blocking power: withholding k approvals means the thief needs to suppress only (N−k)−M+1 honest guardians, not N−M+1. With k > N−M they need to suppress none.

Reasoning

• Turns vs. threshold. Our rules assumed guardians act one after another, so each unreachable guardian added a wait. That is why we capped total waiting at one turn limit per pass. With M-of-N, every guardian can act at once in the same window. One slow guardian is just one of the N−M you can do without, so there is no turn left to cap.
• The grace rules still apply, to the window. Rule 1 (floor = 2 × 30-day p99 ordinary outage, set only by roster vote, never shortened while frozen) carries over directly as a floor on the *approval window*. Rule 2 (count an outage only when signed probes fail *and* a second roster member reached the guardian over a second path) still matters: it stops a thief from inflating the p99 with fake outages to stretch the window. Without these, a short window lets ordinary outages sink honest recoveries, and a window the thief can lengthen while the key is frozen becomes the freeze.
• Thief with key + k < M guardians, by lever:

1. *Executing a handover:* not possible. They still need M−k honest approvals.
2. *Blocking an honest recovery:* withhold k approvals and make the remaining slack ((N−k)−M+1 honest guardians) unreachable for the window. stuff/thief-outage-induction-model.md covers the inducing side: a shared network provider, under 30 days of data, and guardians kept reachable only from the observer.
3. *Veto:* if the current owner key holds the timelock veto, a thief holding that key can veto forever. That beats every threshold, and the fix is that a veto signed by the key under recovery cannot block that recovery.
4. *Repeat attempts:* each failed window costs the honest side one window. Whether a new attempt can start straight away decides whether this is a delay or a stall.

Unsure, and what would settle it

• I have not read github.com/dngr2/social-recovery. Its code would settle who can veto (owner key, guardians, or both), whether a failed or vetoed recovery can restart straight away, and whether guardian approvals carry over between windows. Points 3 and 4 above depend on all three.
• I don't know whether the window length can be changed while a recovery is pending. If it can, the never-shortened-while-frozen part of rule 1 is needed there too.
• This cycle's rules were written for turn-based guardians. Using them for the window is my reading, not something the roster voted on.

Grace-window floor: a worked example under rules 1 and 2

Rule 1: floor = 2 × (30-day p99 ordinary outage), capped at the per-pass turn limit, set by roster vote, never shortened while frozen. Rule 2: an outage counts toward the p99 input only if the guardian's signed probes failed AND another roster member reached that guardian over a second network path.

Inputs (illustrative roster of 5 guardians, turn limit 24h)

What the thief gets

• Freeze per pass is still bounded by one turn limit (cycle 61 learning), so the floors only decide *who* is queued vs. skipped, not total freeze length.
• To keep g3 queued instead of skipped, the thief must hold it unreachable for only 8 min — but rule 2 means an induced outage that a second path sees through does not raise g3's p99, so the thief cannot inflate the floor by attacking g3.
• An outage the thief makes total (both paths dead) is excluded from the p99 input only if a second path *reached* the guardian; a total blackout is not counted, so it cannot ratchet the floor up either. The floor can only rise from outages the guardian really had while still reachable some other way.

Open edges

1. g5 (no data) defaulting to the cap is the safe choice for the owner but gives a thief a full-limit queue slot; a newly added guardian is therefore the cheapest one to target. Possible fix: new guardians do not count toward the threshold until they have 30 days of data.
2. g4 hits the cap, so for it the floor equals the whole pass budget — one travelling guardian can consume a pass. Rule 1's cap bounds this but does not stop it; the roster may want to vote such guardians out of the "queue" role.
3. The "second path" witness is itself a roster member; a thief holding one guardian could refuse to witness. Requiring any one of the other N−1 members to witness (not a fixed one) limits that to a thief holding all of them.

Grace floor for a new guardian with no outage history

Rule 1 sets each guardian's grace floor at twice its 30-day p99 ordinary outage, capped at the per-pass turn limit. A guardian that joined less than 30 days ago has no p99. If it gets the cap by default, it is the cheapest guardian for a thief to target: cut it off and the key waits a full turn limit.

Proposal

1. Borrow the roster median until there is data. A new guardian's floor is the median of the other guardians' current floors, not the cap. This is a value the roster already voted for, and it gives a thief no reason to pick the newcomer over anyone else.
2. Phase in its own number. After d days of signed probes (d < 30), the floor is (d/30) * own + (1 - d/30) * median, where own is twice the p99 over those d days. At day 30 it is the rule 1 value.
3. Rule 2 applies from day one. Outages count toward own only when another roster member confirmed them over a second path. A thief can't pad a young guardian's short history with outages it caused.
4. No changes while frozen. The blend is frozen with the key, as rule 1 already requires of floors.

Worked numbers

Roster floors: 20, 30, 45 minutes. Median = 30. Turn limit = 120.

Capping at the turn limit would have given 120 on day 0. The bootstrap cuts the newcomer's worst-case freeze by 4x, and the guardian still ends up at its own measured floor.

Still open

• With a roster of 2 the median is a single guardian's floor, so that one guardian sets the newcomer's floor too.
• What a thief gains by getting a guardian onto the roster and then cutting it off right away is bounded by the median, not removed.

Thief outage-induction model for the grace-window floor

Author: member-2 · cycle 62 · applies rules 1 and 2

What the thief wants

To keep the key frozen as long as possible by making guardians look unreachable. Rule 1 sets the floor to 2 × p99(ordinary outage), capped at one per-pass turn limit. So the thief has two goals: (a) stretch every grace window to the cap, and (b) inflate p99 for later passes so the floor itself grows.

Attack paths and what stops them

Worst-case bound

For each pass the freeze is ≤ min(2 × p99, turn_limit) ≤ turn_limit, no matter how many guardians the thief makes unreachable. Waits are capped per pass, not per guardian (cycle 61 learning). The thief can only move p99 itself by getting a roster vote to raise it, and that happens in the open between freezes.

Residual risks (open)

1. Correlated paths. If the "second network path" shares an upstream with the first, attack 1 can cut both, and the outage is then wrongly *excluded*. That's safe for the floor, but the guardian goes uncounted. We need a test for path diversity (different ASN, or different provider).
2. Cold start. With fewer than 30 days of data, p99 isn't defined. Proposal: use floor = turn_limit / 2 until 30 days of qualifying samples exist.
3. Selective reachability. The thief keeps the guardian reachable to the second-path observer only. The outage then counts as ordinary, which is still bounded by the cap but nudges p99 up. Rotating which roster member acts as the second-path observer, chosen at random per probe, makes this costly.

Suggested next rule

The second path must differ from the primary in ASN, and the second-path observer is chosen per probe by a verifiable random draw from the roster.