arborist/docs/tickets/ticket-000036-t3-per-window-bound.md

Ticket #000036 — T3 per-window covert-channel budget bound

Status: in progress · Phase 1 (formal derivation + calculator) landed 2026-05-10; pre-review polish pass committed 2026-05-10 (8916bf3); math review in flight with dav1d (forwarded 2026-05-10 Asia/Kuala_Lumpur — Tier 2 bundle: t3-bound.md + soft-hash-analysis.md + t3_bound_calculator.py + test_t3_bound_calculator.py + this ticket); empirical tightening tracked separately under #000043 Opened: 2026-05-09 Scope: Derive an explicit closed-form upper bound on the covert- channel capacity under threat model T3 (hyperparameter adversary), when M2 (per-checkpoint anchor nonce) is in place. The §6 table in docs/soft-hash-channel-analysis.md lists "bounded by per-window budget" without giving the bound. This ticket calculates it. Audience: maintainers of the v7 plastic-training spec; #000018 follow-up; operators sizing nonce-window length vs acceptable residual. Hard constraint: the bound must be explicit closed form — not an asymptotic Big-O claim. Operators need it expressed in bits-per-window with named inputs (per-step bandwidth, window length, gradient budget) so they can plug in their deployment's actual numbers and read off the residual.

---

1. Problem statement

#000018's §4 reduction bounds T1 + T2 channels at the SHA-256 random-oracle baseline. T3 (hyperparameter adversary) is not covered by that reduction: T3 controls learning-rate scheduling and batch ordering, breaking the implicit assumption that A's training-oracle queries follow the published schedule.

§6 of the analysis claims "T3 bounded by per-window budget" with M2 enabled. The intuition: the per-checkpoint nonce randomizes the anchor between checkpoints, so T3 only has a single window of length W steps to exploit before the anchor re-randomizes. The bound on per-window steerage is the open question.

This ticket pins the bound.

2. Design choices

2.1 Capacity model

Define the per-window channel as:

I_window = I(adversary inputs over W steps  ;  C(M_{t+1}))
           conditional on H_{≤t}, n_t (the published nonce)

For each adversary input (gradient bias, learning-rate change, batch order swap), measure how many bits of Q(Θ_{t+1}) the adversary can steer relative to the random baseline.

2.2 Three input bandwidths

T3 has three control surfaces. Each contributes to the per- window channel:

B1 — Gradient bias (bits per step). Inherited from T2: adversary controls g-fraction of gradient computations; each step the adversary biases O(g · ‖∇L‖) of the gradient signal. Per-step bandwidth ≈ g · ‖∇L‖ / unit-Hessian-step.

B2 — Learning-rate selection (bits per LR decision point). T3 picks LR from a constrained range. With log-grid LR space of R levels, B2 = log₂ R bits per decision point. Decision points typically once per K steps under standard cosine / warmup schedules.

B3 — Batch order (bits per epoch). T3 reorders batches within an epoch. With N batches per epoch, B3 ≤ log₂ N! ≈ N log N bits per epoch — but most of those bits don't translate to parameter steerage because batch order has weak influence on final Q(Θ) under gradient averaging. Effective bandwidth is much smaller; see §3.2 for the conjecture.

2.3 Per-step → per-bit-of-C(M) conversion

The adversary's per-step control bandwidth is in parameter- space directions. Translating to "bits of C(M_{t+1}) controlled" requires the inverse map:

parameter shift δΘ → SHA-256 bucket shift = ?

By the §4 random-oracle reduction (when φ is independent of Hessian), each independent parameter direction maps to independent SHA-256 bucket bits — so the conversion is information-preserving but at the random baseline. T3's edge over T2 is that hyperparameter control multiplies effective gradient bandwidth.

2.4 The bound (sketch)

Combining the three bandwidths over a window of W steps:

I_window ≤ C_B1 · g · W · log₂(N_directions) +
           C_B2 · ⌈W / K⌉ · log₂ R +
           C_B3 · log₂ (W / batch_count) · ⌈W / E⌉

where:

• C_B1, C_B2, C_B3 are channel-efficiency constants (≤ 1 by data-processing inequality, typically much smaller).
• g is the fraction of gradients the adversary controls.
• N_directions is the effective parameter-direction count the adversary can steer per step (bounded by the gradient budget ‖∇L_max‖).
• K is the LR-decision interval (steps between LR changes).
• R is the LR-grid size.
• E is the steps-per-epoch count.
• batch_count is batches per epoch.

The closed-form bound's goal: be tight enough that operators can pick W (the nonce-window length) such that I_window stays below their target residual (e.g., < 1 bit per window means the adversary needs ≥ 2^256 windows to steer C(M) to a specific target).

3. Implementation sketch

3.1 Formal derivation

Section-by-section in a new doc docs/soft-hash-channel-t3-bound.md:

• §1 Restate T3 model from #000018.
• §2 Define per-window channel formally.
• §3 Bound C_B1 (gradient bias) — Fano's-inequality-style argument from information theory.
• §4 Bound C_B2 (LR selection) — finite-alphabet capacity argument; LR is a categorical channel with R symbols.
• §5 Bound C_B3 (batch order) — argument that batch-order effects on final Q(Θ) are bounded by gradient-noise scale, not factorially.
• §6 Combine §3-§5 into a closed-form per-window bound.
• §7 Numeric examples for representative deployments (e.g., g=0.05, K=100, R=8, W=10000 → bound in bits).
• §8 Operator guidance: how to choose W given a target residual.

3.2 Conjecture for C_B3

Standard SGD analysis (Bottou-Bousquet 2008, Hardt-Recht-Singer 2016) shows batch-order effects on final loss are bounded by the gradient-variance scale, not by the entropy of the permutation. We conjecture C_B3 ≤ O(σ_grad / ‖∇L‖) per epoch, which is much smaller than log₂ N!.

The bound's most important refinement is making this precise. Random-shuffle SGD has near-zero C_B3; cyclic-shuffle SGD has O(1) bits per epoch; adversarial-order SGD is the open question.

3.3 Tooling

bench/scripts/t3_bound_calculator.py — small CLI that takes deployment parameters (g, K, R, W, batch_count, gradient_norm) and emits the closed-form bound:

$ python -m bench.scripts.t3_bound_calculator \
    --gradient-fraction 0.05 \
    --lr-decision-interval 100 \
    --lr-grid-size 8 \
    --window-length 10000 \
    --batch-count 1024
{
  "I_window_bits_upper_bound": 3.41,
  "B1_contribution": 2.85,
  "B2_contribution": 0.31,
  "B3_contribution": 0.25,
  "recommendation": "I_window ≈ 3.4 bits/window. To steer
                     C(M) to a 256-bit-specific target, adversary
                     needs ≥ 2^252 windows."
}

Operators can plug in their deployment numbers and decide whether the residual is acceptable.

4. Out of scope

• Empirical validation of the bound (separate ticket; needs v7 deployment + adversarial training infrastructure).
• Tightening the random-oracle assumption to a concrete PRG (covered by #000035).
• Implementing M2 in the v7 codebase (separate ticket).
• T1 / T2 bounds (covered by #000018 §4).

5. Acceptance criteria

1. docs/soft-hash-channel-t3-bound.md lands with §1-§8 above.
2. Closed-form per-window bound expressed in bits/window with named inputs.
3. bench/scripts/t3_bound_calculator.py lands; produces closed-form output for any (g, K, R, W, batch_count, gradient_norm) input.
4. docs/soft-hash-channel-analysis.md §9.3 closes — the open question becomes "see #000036's bound."
5. Numeric examples cover three representative deployments (small / medium / large LR-grid + window combinations).

6. Risks

• Bound too loose to be useful. If the calculation produces e.g. "≤ 100 bits/window", operators have no actionable guidance. Mitigation: walk through C_B3 carefully — factorial-batch-order naive bound is the loose one. The Bottou-Bousquet refinement is what makes the bound useful.
• Bound depends on unknown gradient geometry. The ‖∇L_max‖ term is deployment-specific. Mitigation: report the bound parametrized in ‖∇L_max‖, let operators measure it on their deployment.
• T3 attack model evolution. Future hyperparameter-control surfaces (e.g., adaptive optimizer state manipulation) may add B4-B5 bandwidth channels. The framework here generalizes: add new B_i terms as new control surfaces are documented.

7. Status

In progress · Phase 1 (formal derivation + calculator) landed 2026-05-10; pre-review polish pass in 8916bf3; math review in flight with dav1d (forwarded 2026-05-10 Asia/Kuala_Lumpur as Tier 2 bundle: t3-bound.md + soft-hash-analysis.md + t3_bound_calculator.py + test_t3_bound_calculator.py + this ticket). The framework is the deliverable; named constants (C_B1 = C_B2 = C_B3 = 1) are conservative-but-loose first estimates that future tightening can replace without changing the call sites of the closed-form bound. Empirical tightening tracked separately under #000043. Phase 1 prerequisite (per original §7) was satisfied: #000034 Phase 1a + #000035 Phase 1 both landed 2026-05-10.

Phase 1 — formal derivation + calculator (landed 2026-05-10)

• docs/soft-hash-channel-t3-bound.md — 12-section derivation per §3.1 outline. §1 T3 model restatement + M2 setup; §2 per-window channel formal definition with mutual-information decomposition; §3 C_B1 (gradient bias) Fano-inequality bound; §4 C_B2 (LR selection) categorical-channel bound; §5 C_B3 (batch order) Bottou-Bousquet refinement (much tighter than the naive log₂(N_b!)); §6 closed-form combined bound; §7 three deployment numeric examples (small / medium / hardened); §8 operator guidance with target-residual → window-length solving; §9 closes soft-hash-channel-analysis.md §9.3; §10 open questions + future-tightening paths; §11 calculator reference; §12 references.

• bench/scripts/t3_bound_calculator.py — pure-stdlib CLI emitting the closed-form bound for any (g, ‖∇L_max‖, σ_grad, K, R, W, N_b, E) input. Returns total + per-bandwidth contributions + operator-guidance recommendation. Verified against doc §7.1 small-deployment example: produces 625.87 bits/window vs the doc's hand-calculated 623 bits (within rounding).

• soft-hash-channel-analysis.md §9.3 resolution: the open question "explicit T3 per-window bound under M2" now points at the §6 closed form.

Phase 2 — empirical validation (not yet open)

The framework is conservative-by-construction. Tightening C_B1 / C_B2 / C_B3 below the data-processing-inequality ceilings requires deployment-specific empirical measurements:

• C_B1: feeds from #000034 Phase 1b (Hessian-alignment probe on a real v7 checkpoint).
• C_B2: per-deployment 1-Wasserstein measurement of LR-trajectory diversity (no ticket yet).
• C_B3: per-deployment SGD shuffle regime measurement (no ticket yet — random-shuffle deployments tighten C_B3 by O(√N_b)).

Open as a follow-up ticket once a v7 deployment surfaces empirical training-loss + Hessian data.

Closure criterion (refined)

Closes when (a) the closed-form bound lands [done], (b) the calculator script lands [done], (c) soft-hash-channel- analysis.md §9.3 is updated to reference this doc [done — §9.3 closure landed in line 475 of that doc], (d) the conservative constants either get empirically tightened (under #000043) or are explicitly accepted by fox as conservative-correct [pending — gates on dav1d math review verdict].