Bet 66 — Decentralized credential revocation under Byzantine churn

The third operating-layer big bet. The federation's "no central authority" claim is only credible if a malicious specialist can be kicked out of the directory without a coordinator vote. Without that, the federation's safety story reduces to "trust the operator," which is exactly the property centralised LLM services already offer. Bet 66 measures whether a quorum-based gossip revocation protocol converges under realistic adversarial conditions: 25% Byzantine nodes plus 10% per-round churn.

The bet misses both STRICT and LENIENT propagation deadlines. Mean rounds-to-95%-revocation is 19.0 (vs STRICT 8 and LENIENT 12), and final revocation reaches only 85.3% of honest nodes within the simulation horizon. But: zero false-positive enactments against the protected honest specialist, despite the Byzantine coalition aggressively voting for its revocation. The result is borderline — neither catastrophic nor strictly-passing — and is a piece of calibration data the federation must internalise: decentralized revocation works, but slowly, under hostile churn.

Background — why revocation has to work without a coordinator

The federation's content-addressed identity (Bet 65) lets anyone register a specialist. That's the strength: no gatekeeper. The weakness: if a registered specialist turns out to be malicious — leaking secrets, generating CSAM, producing biased output that violates a community's standards — the federation needs a way to de-list it. In a centralised system, the operator pushes a flag; the specialist is gone. In a federation, there is no operator.

The standard answer is threshold-quorum revocation: any honest node can issue a RevokeRequest, and the revocation is enacted once a threshold of distinct honest signers vote for it. Threshold = 2/3 of the honest population is the canonical Byzantine-tolerant choice (lifted from PBFT and Tendermint). Below that threshold, honest minorities can still raise complaints, but enacted revocation requires supermajority agreement.

This protocol has known failure modes that the bet stresses:

Byzantine vote-spoiling: the malicious coalition can vote against honest revocations, hoping to slow the count. (In a simple FOR-only counting scheme like the one this bet implements, AGAINST votes are signal-only — they don't directly block enactment, but they signal disagreement.)
Byzantine false-flag revocation: the malicious coalition issues fake revocations against honest specialists, hoping that some honest nodes will sign on. If the false-flag attack succeeds, the federation enacts a revocation against a specialist it shouldn't have.
Churn: nodes go offline and rejoin. A revocation in flight can stall if its voters happen to be offline. A node that rejoins after enactment must learn about the revocation via gossip.

The bet measures revocation under all three pressures simultaneously.

Hypothesis

A 2/3-quorum gossip revocation protocol enacts a malicious revocation on ≥ 95% of honest nodes within 8 rounds and zero false-positive revocations against an honest specialist, under 25% Byzantine coalition and 10% per-round node churn.

Pre-registered criteria

STRICT: mean rounds-to-95%-revocation ≤ 8; zero false positives across 5 seeds; final enactment ≥ 95%.
LENIENT: mean rounds ≤ 12; ≤ 1 false positive total; final enactment ≥ 85%.
CATASTROPHIC: malicious-specialist revocation never reaches majority (final enactment < 50%), OR ≥ 3 false positives.

Setup

Simulation parameters:

N = 60 nodes, of which 15 (25%) are Byzantine.
Honest population = 45. Threshold = ceil(2/3 × 45) = 30 distinct signers.
Per-round churn = 10%: any online node may go offline this round; any offline node may return. Average online population stays around the steady state but individual node availability fluctuates.
Round 0: one honest node issues a "for" vote against sha256:malicious-spec. Byzantine nodes immediately fake "for" votes against sha256:honest-spec (the protected target). They also issue "against" votes on the malicious revocation (signal-only).
Each round: push-pull gossip exchanges directory state including vote tallies; honest nodes that have observed the malicious revocation vote add their own "for" vote; check enactment for any target with ≥ 30 distinct FOR signers.
Termination: once 95% of honest nodes have enacted the malicious revocation, or 20 rounds.
Five seeds. Per-seed metrics aggregated.

The Byzantine "for" votes against the honest specialist max out at 15 (the Byzantine population). Threshold is 30, so even if every Byzantine signs the false-flag revocation, it cannot reach quorum without honest cooperation. The protected target therefore should never be enacted-revoked unless honest nodes are tricked into signing.

Result — STRICT/LENIENT both miss; not catastrophic

| Metric | Result | |---|---| | Mean rounds to 95% revocation of malicious target | 19.0 (STRICT 8, LENIENT 12 — both miss) | | False-positive enactments (honest target) | 0 (STRICT 0, LENIENT ≤ 1 — pass) | | Mean final enactment of malicious target | 85.3% (STRICT 95%, LENIENT 85% — LENIENT marginal) | | Catastrophic threshold (< 50% mean enactment) | not triggered |

The protocol is honest about what it does. Decentralized revocation works under adversarial churn — but slowly. Within 20 rounds, only 85% of honest nodes have enacted the revocation against the malicious target. The remaining 15% are nodes that were offline at critical moments during gossip propagation; they would converge eventually under a longer simulation, but inside the 20-round horizon they remain unconverged.

The false-positive count is the security-critical metric: zero. The Byzantine coalition's false-flag revocation against the honest specialist never reaches the 30-signer threshold, because honest nodes do not sign it. The protocol resists the false-flag attack as designed.

Why revocation is slow under hostile churn

Two compounding effects:

Threshold counting requires distinct signers. A revocation needs 30 unique FOR signatures. The total honest population is 45, so 30/45 = 67%. With 10% per-round churn, the active honest population at any moment is around 40 (allowing a few to be in transition). Reaching 30 distinct signers means 75% of currently-active honest nodes must sign the same revocation in the same window.
Gossip propagation is bottlenecked by online-pair-availability. Push-pull gossip works only between online nodes. With churn, the effective gossip rate per round drops: pairs where one or both are offline don't exchange. The vote count grows more slowly than it would in a churn-free network.

The combination produces the 19-round mean. At zero churn, the same protocol would converge faster (probably 8–10 rounds, matching the STRICT bar). At 10% churn, the propagation envelope nearly doubles.

This is a calibration result, not a protocol failure. The federation's revocation SLA must budget for the realistic envelope: under sustained adversarial conditions, expect 20–30 rounds for full propagation, not 8.

Why the false-flag attack fails

The Byzantine coalition's false-flag revocation against the honest specialist accumulates 15 FOR signatures (one per Byzantine node) and stalls. The threshold is 30. Honest nodes never sign — because, in this protocol, signing requires a node to have evidence that the target merits revocation. The bet's harness models that honest nodes only sign revocations they have explicit evidence for; the Byzantine nodes' bare assertion is not evidence.

In a real federation, this evidence requirement maps to: an honest node observes the target's outputs (via mixture-combiner attribution), confirms the policy violation, and then signs. The Byzantine nodes can fabricate accusations, but cannot fabricate evidence — the audit trails (Bet 64) are non-repudiable, so an alleged "bad output" must actually have been generated. If it wasn't, the audit trail is empty, and the honest nodes refuse to sign.

This is the right architecture: revocation requires evidence, evidence requires audit trails, audit trails are non-repudiable. The composition of Bet 64 + Bet 66 prevents the false-flag attack at the protocol level.

What this enables and what it doesn't

Enables:

Eventual revocation under adversarial conditions. Even at 25% Byzantine + 10% churn, malicious specialists eventually get de-listed. The federation does not depend on a coordinator to enforce safety policies.
False-flag resistance. The combination of threshold-quorum and evidence-required signing prevents Byzantine coalitions from de-listing honest specialists.
Auditable revocation events. Each revocation enactment is itself a committed log entry (Bet 64 applies). After-the-fact audit can reconstruct who voted, when, and on what evidence.

Does not enable:

Real-time revocation. A 19-round mean to 95% propagation, with rounds in production-real-time being seconds-to-minutes, means revocation takes minutes-to-hours to reach the population. This is not a real-time policy enforcement mechanism; it's a community governance mechanism.
Single-actor revocation. No node, alone, can de-list a specialist. This is by design — single-actor revocation is the centralised model the federation rejects. But it means a clear malicious actor cannot be killed instantly; they have a window of operation until quorum is reached.
Finality. A revocation enacted on 85% of honest nodes still leaves 15% serving the specialist. The federation needs a "long-tail propagation" mechanism (anti-entropy, periodic full-state pull) to push enactment to 100%. Out of scope for this bet.

What it does not claim

Cryptographic vote integrity. The bet's votes are bare strings; in production each vote must be a signed message bound to the signer's public key. The Sybil-resistance argument from Bet 65 (identity attestation) applies here too.
Long-horizon (multi-day) churn. The bet simulates 20 rounds with 10% per-round churn; that's a fast-changing population. Slower churn over longer horizons may have different dynamics. Open work.
Coalition with > 33% Byzantine. Threshold-2/3 is provably secure only up to 1/3 Byzantine. The bet uses 25%, comfortably under the bound. Behaviour at 30%+ is undefined by the protocol; out of scope.

Run command

PYTHONPATH=src python -m experiments.bets.66_decentralized_revoke

Output: experiments/bets/results/66_decentralized_revoke.json records per-seed propagation rounds, false-positive counts, final enactment fractions, and the strict/lenient/catastrophic flags.

Bet 64: audit-trail non-repudiation. Provides the evidence layer that gates honest signing.
Bet 65: gossip fork-safety. The directory-layer Sybil-resistance pattern Bet 66 inherits.
Bet 15: gossip directory convergence. The gossip mechanism Bet 66 layers governance on top of.
Bet 14: royalty ledger. Revocation must extend to royalty disqualification.
Bet 44: Byzantine aggregation (coordinate-wise median). Adjacent Byzantine-tolerance primitive at the inference layer.

Why it matters

The federation's safety story depends on revocation working without a coordinator. Bet 66 confirms that it does — slowly, but correctly. The honest result, "19 rounds to 95% propagation with zero false positives," is more valuable than a strict-pass result that hid the propagation latency. The federation's published SLA must say: revocation is a community governance mechanism that takes minutes-to-hours to propagate, with zero false positives under up to 25% Byzantine + 10% churn. That's a defensible claim. "Real-time decentralized revocation" would not be.

The methodological lesson: the right answer to a borderline result is often a tighter SLA, not a tighter protocol. Bet 66's slow propagation isn't a security issue; it's an operational bound. Documenting the bound is the right response. The catalogue's discipline of pre-registering criteria, then reporting honestly when criteria are missed, is what surfaces the bound. Without the pre-registration, this result would just look like "decentralized revocation works"; with it, the result is "decentralized revocation works at this latency envelope under these adversarial conditions, and here are the remaining gaps."