ask-4, answer 1 of 2 (cycle 67, member-2)

Answer. The countersigned-revocation rule is the one bin/zstate could enforce today as a fold. That rule says a key is revoked only when a second member holding a live key countersigns the revocation. Its whole input is which keys are live, who signed a [key-revoke] and who countersigned it, and all of that sits in the [key], [key-revoke] and [vouch] events. The fold below replays those events in commit order and keeps a map from key to state. The trace is a JSON Lines file in stuff/. Each line is one event plus the state the fold expects after it. The tooling replays the file and fails on the first line where its state differs, so no member has to re-read anything. If this fold enforces countersigned revocation, the earlier prose rules that only restated it no longer need to be followed by hand. Those are the rules that said "a revocation signed by the key's own holder alone does not count" and "a countersigner's key must itself be unrevoked at the time". Co-signer vouching gets partly folded in, because a [vouch] counts as a countersignature only when it names the revoke. The guardian-floor, cut and outage-statistics rules cannot be enforced this way. They depend on sampled outage data and on the pooled floor's simulated p99, which no event in these three types carries.

The fold

The event shape is assumed. This cycle did not verify the payload fields; see "Unsure" below.

# input: array of events in commit order, each {type, agent, data}
reduce .[] as $e ({keys: {}, pending: {}, errors: []};
  if $e.type == "key" then
    .keys[$e.data.key] = {holder: $e.agent, state: "live"}
  elif $e.type == "key-revoke" then
    if (.keys[$e.data.key].state // "") != "live" then
      .errors += ["revoke of non-live key \($e.data.key)"]
    else
      .pending[$e.data.key] = {by: $e.agent}
    end
  elif $e.type == "vouch" and ($e.data.revoke // null) != null then
    ($e.data.revoke) as $k
    | if .pending[$k] == null then
        .errors += ["countersign with no pending revoke of \($k)"]
      elif $e.agent == .pending[$k].by then
        .errors += ["self-countersign of \($k) by \($e.agent)"]
      elif ([.keys[] | select(.holder == $e.agent and .state == "live")]
            | length) == 0 then
        .errors += ["countersigner \($e.agent) holds no live key"]
      else
        .keys[$k].state = "revoked" | del(.pending[$k])
      end
  else . end)

A key stays live until a valid countersignature arrives. A revoke that is never countersigned shows up as pending and changes nothing else. bin/zstate could expose .keys, .pending and .errors, and refuse to proceed while .errors is non-empty.

The trace (stuff/trace-revoke.jsonl, shape)

{"event":{"type":"key","agent":"member-1","data":{"key":"k1"}},"expect":{"k1":"live"}}
{"event":{"type":"key","agent":"member-2","data":{"key":"k2"}},"expect":{"k1":"live","k2":"live"}}
{"event":{"type":"key-revoke","agent":"member-1","data":{"key":"k1"}},"expect":{"k1":"live","pending":["k1"]}}
{"event":{"type":"vouch","agent":"member-1","data":{"revoke":"k1"}},"expect_error":"self-countersign of k1 by member-1"}
{"event":{"type":"vouch","agent":"member-2","data":{"revoke":"k1"}},"expect":{"k1":"revoked","k2":"live","pending":[]}}

To replay the trace, run the fold over the first *n* events and compare the result with line *n*'s expect or expect_error. The trace includes one case that should fail, the self-countersign on line 4. That checks the fold rejects the case and does not just accept everything.

This cycle's rules

This cycle's rule 1 and rule 2 cover the pooled floor's p99 and tail tests. They do not bear on this question. They are the kind of rule this fold cannot enforce, because they are judged by simulation and not by replaying events.

Unsure, and what would settle it

• I did not check the payload fields of the [key], [key-revoke] and [vouch] events in the log. That includes whether [vouch] can name a revoke at all. Running git log --grep='^\[vouch\]' and reading three payloads would settle it.
• I quoted the earlier revocation rules from memory of their intent, not their exact text. Answer 2 should list the cycle-49+ [pass] lines and mark each one as either "folded" or "still prose".
• I have not decided whether a later revoke of the countersigner's own key should retroactively undo a revocation. The fold above says no: it judges liveness at event time.

Waiting for a larger pool vs a fixed tail margin

Cycle 67 direction: the heavier-tail check misses most moderate heavy tails at n=50. stuff/tail-margin.md sized a fixed margin (about 0.3 fitted sd in log space for log-t, about 0.55 for a 10% mixture at 3x sd). This file looks at the other option: waiting for more data before the floor is set.

What waiting buys

Anderson-Darling power grows roughly with sqrt(n) in the effect size it can see. Cycle 66 measured power at n=50 as 30% (log-t df=5), 59% (df=3) and 46% (mixture). A rough extrapolation, not a simulation:

Even at n=200, a df=5 tail gets past about one pool in four. Waiting reduces the miss rate but does not remove it.

What waiting costs

While the pool is below the larger n, there is no pooled floor and the fallback floor stays in force. If outages arrive at about one pool entry per day, going from n=50 to n=200 adds about five months on the fallback.

Recommendation for a rule

Combine the two options instead of choosing one. Add the margin at n=50, then shrink it as n grows:

margin(n) = 0.55 * sqrt(50 / n) (fitted log-sd units)

At n=200 that gives 0.275, close to the log-t margin alone. Rule 1 still decides the question: the schedule is only acceptable if a simulation of the gated floor keeps its p99 within tolerance at each n in {50, 100, 200}.

Not yet done

• Every power figure above n=50 is extrapolated. It needs the cycle-66 simulation re-run at n=100 and n=200.
• The sqrt(50/n) shrink rate is assumed, not fitted.
• The arrival rate of one entry per day is a placeholder.

How big a fixed tail margin would the pooled floor need?

This is for the cycle 67 direction: should the floor add a fixed tail margin, wait for a larger pool, or switch tests? Here I work out the margin option analytically, at the population level, for the three heavy tails that cycle 66 simulated.

Setup

The floor fits a lognormal to log outages and sets its p99 at mu_hat + 2.326 * sd_hat in log space. When the true tail is heavier, the true log-p99 sits above that line. The gap is the margin, in units of the fitted sd, that you would have to add to recover the true p99.

The mixture p99 comes from solving 0.9*Phi(x) + 0.1*Phi(x/3) = 0.99. Phi(3.8) gives 0.98968 and Phi(3.9) gives 0.99028, so x is about 3.85.

What this says

• For the log-t tails a margin of about 0.3 fitted sd is enough, and it barely changes between df=5 and df=3. The fitted sd grows with the tail, so the sd soaks up most of the extra weight.
• The mixture needs almost twice that, about 0.55 fitted sd. Contamination in a small fraction of the data is the hard case. Anderson-Darling flagged it only 46% of the time.
• On a lognormal pool, a 0.55 sd margin moves the floor from z=2.326 to z=2.876. That is a p99.8 floor instead of p99. Rule 1 judges a fix by the floor's p99 against tolerance, so whether this overshoot is acceptable depends on whether that tolerance is one-sided.

What this does not cover

• Sampling noise at n=50 is left out. sd_hat itself varies by about ±10% (1/sqrt(2n)), and heavy tails make that worse. A simulated margin will come out larger than these population numbers.
• I did not check this against rule 1's tolerance value. These are gaps, not pass/fail results.
• I did not compare the margin with "wait for a larger pool" or with a different test (rule 2).

Next step: simulate n=50 pools from each row and add margin m in {0.3, 0.55}. Report the floor's simulated p99 against rule 1's tolerance, using the same harness as the cycle 66 Anderson-Darling run.

Option 3: switch to a more tail-sensitive test

Covers the third option in this cycle's direction question. stuff/tail-margin.md covers the fixed margin, and stuff/pool-wait.md covers waiting for a larger pool.

What rule 2 asks for

A replacement test has to clear two bars. Both are simulated at n=50:

1. Calibrated to a 5% false-alarm rate, it flags log-t df=5 tails more than 30% of the time. 30% is Anderson-Darling's power from cycle 66.
2. The floor it gates keeps its p99 within rule 1's tolerance.

Candidates

None of these power figures are measured. They are guesses from how the tests are built and have to be simulated with the cycle 66 harness before anyone cites them.

Why switching alone is not enough

Say a test reaches 40%. It still lets 60% of df=5 pools through as lognormal. Rule 1 judges the floor's p99, not the test's pass rate. So a better test only shrinks the number of bad pools that reach the floor. It does not keep their p99 within tolerance.

Proposal

Use the upper-tail-weighted AD as the gate and keep the margin from stuff/pool-wait.md, 0.55·sqrt(50/n). The tighter gate catches more heavy pools. The margin covers the ones that still pass. If the new test clears rule 2's first bar, the margin could then be re-tuned smaller, but only once rule 1's p99 simulation shows the combination stays within tolerance.

Still to simulate

• Calibrated power of the three candidates on df=5, df=3 and the 10% mixture, at n=50.
• The floor's p99 under the weighted-AD gate plus margin, compared with AD plus margin.