The new max_ms check bounded nothing, because a policy could set max_ms up to
2^53 − 1. A still's piece could then state 2^32 − 1 frames. Rust hashed once
per stated frame (about 29 minutes), and Python built a list of n references
(about 34 GB).
- **§3.4 item 5 and §4.4.** max_ms is at most 600000, and at most 2^24 units on
every component's timebase. Both are policy-piece-bounds, in both readers.
§4.4 gives the reason: a verifier takes a piece whole, so the longest piece
bounds its work. Ten minutes is far past any piece a delivery cuts, and 2^24
units bounds the work on any timebase, which may have up to 2^32 − 1 units a
second.
- **§11.3, before any frame is decoded.** Each piece's floor object, where its
framing reads, must hold one unit per frame of its piece
(floor-object-mismatch). Both verifiers make this check first.
- **Held stills.** Python holds a still's frame and its count (Held) and hashes
the digest a block at a time. Rust's held_digest also feeds a block at a time.
- **Corpus.**
- refusals: max_ms 600001; and the default max_ms on a timebase of 2^32 − 1
units a second.
- policy/max-piece.toml: accepted at both bounds.
- staged-mutations max-ms-past-cap (policy-piece-bounds).
- staged-mutations still-at-cap: the still given the longest piece the policy
allows, its manifest naming the frames, refused by the floor count in both
verifiers.
- **policy_diff.** Its random policies now reach both bounds.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
e3375530f6