Countersigner race: what the thief needs to move a cutoff

Rules 1 and 2 leave one way to drag a key's cutoff earlier: the thief must hold a second key with no countersigned revocation before the forgery. This file checks what that costs and whether the strata stay two-valued.

Setup

Keys A (honest, stolen) and B (also stolen, still unrevoked). Commit log:

Outcome

• Rule 2: B has no countersigned revocation before pos 2, so B's countersignature counts. A's first countersigned revocation is pos 2.
• Rule 1: rescue restores c1 (pos 1 < 2) and drops c2 (pos 3 > 2). The thief moved the cutoff from 4 to 2 and denied c2.
• Each stratum is still a single split at one log position: everything before is restored, everything after is not. Monotone, two-valued.

Race

The forgery also burns B's usefulness only if someone revokes B. Once revoke(B) is countersigned at pos p, rule 2 voids every countersignature B makes after p, but not the one at pos 2. So the honest side wins only by revoking B *before* the forgery lands: it is a race on log position, and pos 2 < pos of revoke(B) means the thief keeps the gain.

Takeaway

Countersigning a revocation raises the price from one stolen key to two unrevoked stolen keys, but does not make the cutoff unforgeable. A retroactive rule (void B's countersignatures once B is shown to have been stolen earlier) would break the "single position" property, since a later event would then move an earlier cutoff back out.

Can a forged revocation drag the cutoff earlier?

Worked trace under rule 1 (cutoff = first *countersigned* revocation, by commit-log position) and rule 2 (a countersigner counts only if it has no countersigned revocation earlier in commit-log order).

Keys: H (honest), A and B (honest peers), T (thief, holds a copy of H's key).

Rescue restores c1, c2, c3 (all before position 5). T's forgery at 3 moved nothing, because rule 1 ignores it until countersigned.

The attack rule 2 closes

Suppose T also stole B, and B was already revoked (countersigned by A) at position 2. T countersigns r1 with B at position 3. Without rule 2, H's cutoff becomes 3 and c3 is lost. With rule 2, B has a countersigned revocation earlier in the log (2 < 3), so B's countersignature does not count; the cutoff stays at 5.

What remains open

If T steals a key that is *not yet* revoked, its countersignature counts. The cutoff can then move as early as the theft of the second key. So the bound is: a forged cutoff needs two live, distinct keys. Each stratum stays two-valued (a cut is before or after one position), and monotone (later countersigned revocations never move the cutoff, since only the first one counts).

Single-pass cutoff: rules 1 and 2 resolve in one walk of the log

Question: if rescue restores only cuts a key signed before its revocation by commit-log position, does each stratum stay monotone and two-valued, and can a forged revocation move that cutoff earlier?

The dependency looks circular but isn't

Rule 1 sets a key's cutoff at its first *countersigned* revocation. Rule 2 says a countersignature counts only if the countersigning key has no counted countersigned revocation *earlier in commit-log order*. So whether K's revocation counts depends on whether J's revocation counted, which depends on J's countersigner, and so on.

Every link in that chain points strictly backward in the log. That makes the dependency well-founded. One forward walk resolves it:

1. Walk events in commit-log order, keeping cutoff[key] (unset at the start).
2. For a revocation of K countersigned by J (J ≠ K): it counts iff cutoff[J] is still unset at this position. If it counts and cutoff[K] is unset, set cutoff[K] to this position.
3. Uncountersigned revocations are recorded and change nothing (rule 1).
4. Once set, cutoff[K] is never touched again.

Consequences

• Two-valued and monotone per key: a cut by K is restored iff its position is before cutoff[K]. Every cut falls on one side or the other, and the restored set is a prefix of K's cuts.
• Stable: a later event cannot move an earlier cutoff. Step 4 never rewrites, and step 2 only reads state from earlier positions. This is the property the retroactive-voiding fix in countersigner-race.md would give up.
• Forgery can still move the cutoff earlier, but only if the forgery lands while its countersigner J is still uncut. Once J has a counted revocation, J cannot countersign anything again. So each stolen-and-unrevoked key can countersign forgeries for others. It can only do that until its own revocation counts.

Example

A thief holding B forges A's revocation at 3 and gets nothing, because B was already cut at 2. Their window was before position 2. This matches the race described in countersigner-race.md, and the walk shows that race is the only remaining attack.