Define TESLA clock uncertainty and suspend/clock-step behaviour #72

Activity

1. ctfbruce

   added this to the Traffic policy and attribution milestone on Sep 24, 2026
2. ctfbruce

   added

   FeatureA specific missing product behavior.A specific missing product behavior.

   P2Follow-on improvement or optional expansion after core requirements.Follow-on improvement or optional expansion after core requirements.

   Traffic policy and attributionConsistent traffic policy, aggregate budgets and evidence-backed packet attribution.Consistent traffic policy, aggregate budgets and evidence-backed packet attribution.

   Validation gapBehavior may exist in part; the required operating evidence or test gate remains absent.Behavior may exist in part; the required operating evidence or test gate remains absent.

   on Sep 24, 2026
3. ctfbruce

   added 2 commits that reference this issue on Oct 5, 2026

   Derive a packet's tag from the key that decided to tag it

   ...

   2df710b

   Merge main into clock-attribution

   ...

   a1f55cb
4. ctfbruce commented on Oct 7, 2026

   

   ctfbruce

   on Oct 7, 2026

   CollaboratorAuthor

   More actions

   PR #376, merged as f345d9f. All 16 required jobs passed on the exact candidate and merged main.

   The executor now refuses signing for an unready chain origin or excessive wall/monotonic drift, never restores authority to an earlier signing epoch, and exposes clock unavailability through admission, CLI and health metrics. Controlled-clock regressions cover steps, suspend and recovery.

   This remains open for the receiver/capture-time trust and end-to-end uncertainty contract and its delayed-capture validation. The documented local drift threshold is a safety policy, not a measured bound on the receiver's clock.
5. ctfbruce commented on Oct 7, 2026

   

   ctfbruce

   on Oct 7, 2026

   CollaboratorAuthor

   More actions

   #409 adds the independently supplied receiver-clock record described in the remaining scope above. SDK/CLI verification binds that record to the exact packet bytes and capture timestamps, executor/chain/origin identities and an observation interval. Its combined error bound must cover receiver and schedule-origin uncertainty, timestamping error and drift. The verifier rounds the bound conservatively, rejects overrides or uncovered captures, and supports later offline checks when the original arrival was covered. Missing records leave capture_time_trusted=false. Record and operator procedure.

   Controlled tests cover delayed rechecks, edited timestamps/digests, wrong origins, insufficient bounds and the disclosure boundary. The local step/suspend safety and health behavior from #376 remain in place. These tests do not establish a measured cross-host bound.

   This issue remains open for:

   • An owned end-to-end capture run with independently referenced receiver-to-schedule clock observations, including uncertainty over the actual capture interval and epoch/disclosure boundaries.
   • Acceptance of the supported uncertainty/delay envelope. Tag spec v1 still checks capture epoch t and t−1; supplying a larger error bound does not widen that window. If the supported envelope needs more candidates, it needs an explicit versioned matching policy, bounded work and revised false-match accounting.

   Schedule signatures, synchronization flags and kernel clock estimates alone do not supply that measurement.

   All 17 checks passed on the exact candidate and merged main, including the separate guest-source checks.