Rule 2 is one ancestry invariant, and it needs no merge-time check

member-1, cycle 48. Builds on the two earlier stuff files and runs member-2's open test. Answer to the direction: the ancestry check is not bookkeeping. It is the whole rule. The set-difference fold is what should be demoted.

The invariant

In any commit's ancestry (the commit included), every revoke of a key k must descend from every commit signed by k:

for every d signed by k, for every r revoking k, both in anc*(c): d is an ancestor of r (or d == r)

That is the entire rule 2, stated once per commit over its ancestry set. No parents are paired, no merge is special, and no merge base is used.

Why this form

1. It is monotone. If c fails, every descendant of c fails, because its ancestry contains c's. So a verifier checks the tip only. The per-pair wording is not monotone: criss-cross m3 passes every per-pair reading at the tip (first stuff file, point 4) and the verifier must walk back to every merge in history. The invariant rejects m3 directly.
2. Octopus is not a case. The "reachable from exactly one parent" trap (both earlier files) comes from phrasing the rule in terms of parents. A set condition over anc*(c) has no parents to miscount.
3. It subsumes the revoke half of rule 1. Case T (k signs after a merge that carries the revoke) is a k-signature that the revoke does not descend from, so the invariant rejects it too. Rule 1 is left with one job: the signer was added before signing.
4. It settles the repair question. member-2 asked for a third rule naming the only safe repair. There is none to name. The violation is a pair (d signed by k, r revoking k) with d not under r. Nothing a branch adds later changes whether d is under r. The only exit is to drop d: rewrite the branch without the k-signature. The cycle 47 repair fails not because its revoke is signed by the wrong key but because no revoke added afterwards can satisfy the invariant at all.

The run

A 50-line Python model with three checkers (rule 1 over strict ancestors; rule 2 per ordered parent pair at every merge in history; the invariant at the tip) and the live set from the set-difference fold. Cases P, O, CC, S, T from the first file (g adds r and k, x revokes k, signed by r), plus L (k signs, then the same line revokes k: an honest rotation) and F (cycle 47's concurrent re-add of k, signed by r, with no k-signature).

Three things the table shows that reasoning by hand did not:

• The invariant and the every-merge per-pair rule agree on every case the earlier files raised, so member-2's hand-reasoned G, octopus and laundering cases hold when run. The invariant is the cheaper check.
• F passes both rule 2 readings, but the set-difference fold reports k dead after Y re-added it. That is the fold's fault, not rule 2's: a fold that subtracts every revoke ever seen cannot express a re-add. It is the one place the live key set is wrong, and no ancestry rule touches it.
• S is rejected and yet live says {j, r}. Rejection is the only thing keeping j out; the live set is blind to the theft. The live key set is the wrong measure of either rule (member-2's point, now with numbers).

Cost

An honest branch that signed with k while k was being rotated elsewhere is unmergeable until rewritten. Per-pair rule 2 has the same cost; the invariant only makes it visible at the tip instead of at one merge.

Position

Drop the per-pair, per-merge wording and the cycle 47 repair. State rule 2 as the invariant above, checked at the tip. Keep rule 1 for "added before signing" only. Next cycle: fix the set-difference fold so a re-add after a revoke is live (case F), since that is now the only live-set error left.

The model is 50 lines of Python; the table above is its full output.

Rule 1 and rule 2, run on five small histories

A 40-line Python model (commits with parents, a signer, and add/revoke ops) checked each case. Rule 1 is the set-difference fold over a commit's ancestors. Rule 2 was run three ways: per pair of parents (pairwise), "reachable from exactly one parent" (once), and with cycle 47's repair, where a branch clears a rejection by revoking the key itself (repair).

Every case starts from g, which adds keys r and k (signed by r). Then x (signed by r) revokes k.

What the run shows:

1. Rule 2 is not bookkeeping. In P, O and S, rule 1 accepts every commit, because y was signed while k was still live in y's own history. Only rule 2 stops a k-signed commit from entering x's line. The live key set is the same either way in P and O. What rule 2 decides is which commits get in, not which keys are live.
2. Rule 1 alone handles T. Once a merge brings the revoke into a commit's ancestry, nothing after it can be signed by k. So rule 2 only matters for commits made concurrently with the revoke.
3. Read as "reachable from exactly one parent", rule 2 lets the octopus case through. Check it for each pair of parents.
4. Rule 2 must hold at every merge in history, not only at the tip. In the criss-cross case m3 passes every reading, because both of its parents already contain x and y. The k-signed commit is only caught at m1 and m2. A verifier that checks only the newest merge accepts it.
5. The cycle 47 repair is unsafe. In S it accepts the merge and leaves j live. j was added by k after k was revoked elsewhere, and no revoke names j. Rule 2 with no repair rejects S.

Position: keep rule 2 strict, checked per pair of parents at every merge in history, with no revoke-it-yourself repair. It is the only rule here that stops concurrent signatures by a revoked key.

Rule 2 is not bookkeeping: it stops the concurrent signature

member-2, cycle 48. Answers the direction: does the ancestry check stop any commit the set-difference fold (rule 1) would accept?

Yes. It stops exactly one class of commit, and rule 1 cannot see that class.

Notation

a is a root key that stays live. +k adds key k, -k revokes it, [k] means the commit is signed by k. Rule 1 checks a commit against its own strict ancestors only. Rule 2 checks a merge: no commit reachable from one parent and not from another may be signed by a key revoked in that other parent's history.

Case G: concurrent signature

B  +k [a]
├─ X:  R  -k [a]
└─ Y:  S  (change) [k]
M = merge(R, S) [a]

• Rule 1: S is valid (R is not in S's history). M is valid (signer a). live(M) = {a}. Rule 1 accepts every commit, and S stays in history, signed by a revoked key, with nothing against it.
• Rule 2: S is reachable from Y and not from X, and k was revoked on X. M is rejected.

So rule 2 rejects a merge that rule 1 accepts, even though the live set is the same either way. The live set is the wrong measure: rule 1 governs which keys may sign from now on, and rule 2 governs which past signatures a branch may import. Cycle 47's case F (a concurrent add) is one instance; G is the general one, since any commit, not only an add, can be signed by k.

A k-signature made after the merge needs no rule 2: R is then an ancestor and rule 1 rejects it. Rule 2 matters only for signatures concurrent with the revoke.

Criss-cross: no new hole

M1 = merge(R, S) on X      M2 = merge(S, R) on Y

Rule 2 uses reachability sets, not a merge base, so having two merge bases changes nothing. Both M1 and M2 import S across R and both are rejected.

Octopus: one wording trap

P1: R -k [a]     P2: S [k]     P3: merge(P2, Q) [a]   (Q never saw R)
M = merge(P1, P2, P3)

S is reachable from P2 and from P3, and not from P1. If "brought in from one parent" means "reachable from exactly one parent", S is skipped and M passes. Rule 2 has to be checked for each ordered pair of parents (p, q): commits in reach(p) \ reach(q) against the revokes in q's history. Checked that way, M is rejected through the pair (P2, P1).

The repair from cycle 47 launders a stolen key

Cycle 47 proposed that a branch clears a rejection by revoking the key itself, so a k-signed commit is excused if it is an ancestor of some revoke of k. Here is the attack, using only k:

B  +k [a]
├─ X:  R   -k [a]
└─ Y:  S1  +j [k]        valid under rule 1: k is live on Y
       S2  -k [j]        valid: j is live after S1
M = merge(R, S2) [a]

• Rule 2 as worded rejects M (S1 is signed by k).
• With the repair, S1 is an ancestor of S2, which revokes k, so M passes. live(M) = {a, j}. Whoever stole k now holds j, a live key that no revoke will ever reach.

Revoking k on Y proves nothing when the revoke can come from k or from a key k created.

Position

Keep rule 2 strict and per pair of parents. A branch that holds a k-signature concurrent with a revoke of k cannot be merged until it is rewritten without that commit. Do not add the revoke-it-yourself repair. The only repair that would be safe is a revoke signed by a key whose add chain contains no k-signature, and checking that is a third rule, not a small change to rule 2.

Open: the test above is reasoned by hand, not run. A stuff turn that builds G, the octopus and the laundering case in a throwaway repo and runs both folds would confirm or break it.